J’ai atteint un stade agréable dans ma phase d’apprentissage RubyOnRails : je m’amuse enfin avec ce langage ! Oh, je ne sais pas encore tout faire, loin de là, et comme je le disais dans un précédent billet, la phase d’apprentissage n’est pas si courte que cela lorsque l’on vient de PHP ! Mais bon, j’en sais assez pour me permettre d’écrire ce nouveau petit didacticiel destinés à ceux qui veulent faire leur premier pas avec Rails et qui veulent bien le faire !

L’objectif de ce billet est de permettre à chacun de créer son premier site Internet (ou plutôt sa première application) avec Ruby On Rails, depuis l’écriture de la première ligne de code jusqu’à sa mise en ligne. Pour cela il nous faut un sujet, on pourrait prendre l’exemple d’un blog mais certains l’on déjà fait, on pourrait essayer de faire une petite boutique de ecommerce mais d’autres en ont déjà fait livre. En fait, on pourrait « presque » tout faire… mais le but n’est vraiment pas de coder une application complexe, il faut que ce soit simple à écrire et à comprendre !

Je tranche donc, ce sera une petite application de gestion de CDs, basique : ajout de CD, édition, suppression, consultation. C’est pas le graal mais c’est pas le but. Faut que ce soit à la porté de tout le monde afin d’introduire Ruby On Rails.

Préparation du développement.

Avant de coder quoi que ce soit, il nous faut préparer l’environnement de développement. Cet environnement se compose de 2 parties : le moteur (Ruby, Rails, WEBrick ou Mongrel) et l’éditeur (Eclipse, Radrails, TextMate, Vim, et j’en passe…). Il est possible d’installer cet environnement sous Linux, OSX ou encore Windows. Je ne décrirais pas ici comment faire pour installer tout cela mais je vais vous donner les liens pour passer cette étape avec succès.

1. Linux (Ubuntu) : Installer Ruby On Rails & Eclipse (Radrails)
2. OSX : HowtoInstallOnOSXTiger et quelques mots sur TextMate, un éditeur adulé par les inconditionnels de la pomme.
3. Windows : Je ne sais pas trop comment ça se passe sous cet environnement, mais vous pouvez jeter un oeil sur InstantRails (ici en français)
4. (Si vous connaissez d’autres types d’installations ou d’autres bon tutos, faites moi en part dans les commentaires, je les noterai ci dessous !)
5. Windows par Aurélien : Utilisation de WAMP5, la procédure est décrite dans son commentaire en bas de page.
6. __Windows avec EasyRails : Je n’ai pas testé mais cela me semble très prometteur. Le but de ce projet étant d’amener du monde vers Rails, je ne peux qu’aprouver ! (Easyrails)

Petite note personnelle : Je suis sous Ubuntu Linux et j’utilise Radrails en tant que plugin pour Eclipse pour développer, Radrails permet de faire certaines actions grâce à une interface, dans le petit tutorial ci dessous, j’utiliserai directement les commandes à saisir sur votre console (Linux ou Windows)

Création de l’application mesCDs !

On ne peut parler de Rails sans dire 2 mots du fameux Modèle-Vue-Contrôleur (MVC), c’est un patron de conception (design pattern) sur lequel est basé le framework Rails. Pour résumer très rapidement, rails vous permettra donc de mettre en oeuvre chacun des principes de ce MVC. Les modèles seront votre interface de communication avec la base de donnée, les contrôleurs seront le lieux ou vous écrirez vos actions et enfin les vues seront destinées à présenter l’information…

Ce n’est pas grave si tout n’est pas encore clair, le mieux c’est de se lancer !

Création de l’arborescence Rails du projet.

La première étape d’un nouveau projet rubyonrails est la création de ce projet, une commande vous permettra de créer l’arborescence de base et générera certains fichiers indispensables.

rails mesCDs

Une liste de dossier et de fichiers seront donc crées dans le répertoire mesCDs.
Vous pouvez faire un petit tour dans cette arborescence afin de vous familiariser avec le nom des répertoires. Vous trouverez notamment un répertoire ‘app’ dans lequel vous travaillerez le plus souvent, lui même contient 4 sous répertoires dont le nom devrait vous rappeler quelquechose… On retrouve en effet un répertoire pour chaque brique du MVC (models, views, controllers) et un 4ème répertoire appelé « helpers ». Ce dernier contiendra des fichiers qui pourront être apparentés à des bibliothèques de fonctions… On y reviendra plus tard !

Avant d’aller plus loin et pour vous prouver qu’un projet Rails est réellement rapide à mettre en oeuvre, nous allons entrer dans le répertoire mesCD et lancer la commande suivante :

script/server

Vous devriez avoir un message dans ce style parmis d’autre: « Rails application starting on http://0.0.0.0:3000″. Cela veut dire que votre application Rails est lancée et qu’elle est disponible pour test à travers votre navigateur à l’adresse http://0.0.0.0:3000. (0.0.0.0 étant le localhost). Vous venez de lancer un serveur Mongrel, si vous interrompez ensuite ce script vous coupez le serveur Mongrel. Rendez-vous à l’url indiquée (http://0.0.0.0:3000), vous aurez droit au joli « Welcome aboard » : cet écran vous explique comment débuter votre projet. Il est assez minimaliste mais à tout de même le mérite de nous indiquer quelle est notre prochaine étape : la base de donnée.

Connexion d’une base MySQL

Rails est conçu pour développer des applications nécessitant une base de donnée, aujourd’hui c’est quasiment le « sine qua non » des applications modernes. Cependant Rails peut fonctionner sans, je vous laisserai le découvrir par vous même au fur et à mesure de votre apprentissage !

Revenons donc à nos moutons… Il nous faut créer une base de donnée et indiquer à notre nouvelle application comment l’utiliser. MySQL étant le type de base le plus largement utilisé dans la création d’application web nous allons donc travailler avec ! (Il faut savoir que Rails peut fonctionner avec d’autres bases de données relationnelles.)

Ouvrez donc un prompt MySQL (amis windowsiens débrouillez vous avec phpmyadmin ou autre gadget ) et créez votre base :

mysql> create database mescds;

Créez ensuite un couple user/pass pour accéder à votre base de donnée :

mysql> grant all on mescds.* to ‘user’ identified by ‘password’;

La base de données créée et vos informations bien en tête, nous allons maintenant renseigner le fichier de configuration associé. (config/database.yml) Editez le et compléter la partie correspondante :

development:
adapter: mysql
database: mescds
username: user
password: password
host: localhost

Nous n’avons touché que la configuration correspondant à la base de développement car Rails fonctionne par défaut en mode ‘development’, ce mode sera changé lors du passage en production, nous le verrons plus tard lorsque nous mettrons en ligne notre future application…
L’application devrait maintenant être en relation avec votre base de donnée, vous pouvez alors effacer le fichier correspondant à la page d’accueil :

rm public/index.html

et relancer votre serveur Mongrel (interruption du script puis commande script/server à nouveau), la page http://localhost:3000 devrait alors vous afficher une erreur « Routing Error », rien d’alarmant, il faut maintenant coder un peu…

Création du modèle « cds »

Dans une application classique « assez propre », pour gérer une base de donnée de CDs, la première étape assez longue est de créer une table « CDs » puis d’écrire une classe permettant d’exécuter des actions simples telles que ajouter un champs, supprimer un champs, mettre à jour un champs, afficher les champs, etc. Cette étape est grandement simplifiée dans Rails, ActiveRecords (une des parties de Rails) nous fournit ce que l’on appelle une abstraction de la base de donnée.

Voyons maintenant comment l’utiliser. Créons d’abord notre modèle « cd »

script/generate model cd

Si l’on inspecte un peu le retour de cette commande, on observe qu’elle crée 4 fichiers (et un répertoire) :

create app/models/cd.rb
create test/unit/cd_test.rb
create test/fixtures/cds.yml
create db/migrate/001_create_cds.rb

Le premier « cd.rb » est notre modèle (gardez en tête le MVC !), le second « cd_test.rb » est un fichier permettant de tester l’application (je ne m’étendrai pas sur cette partie que je ne maîtrise pas bien), le troisième « cds.yml » est un fichier dans lequel on peut renseigner un jeu de tests (des données fictives de l’application), le dernier « 001_create_cds.rb » est le fichier indiquant comment créer la table « cd » en base de donnée, et c’est d’ailleurs par là que nous allons commencer.

Arrêtons nous une minute, pour réfléchir à notre table CDs : un cd peut être défini par un titre, un auteur et une brève description par exemple. Nous allons donc indiquer ce que nous voulons dans le fichier « db/migrate/001_create_cds.rb » que je vous laisse lire car il est assez explicite :

class CreateCds < ActiveRecord::Migration
def self.up
create_table :cds do |t|
t.column :title, :string
t.column :author, :string
t.column :description, :string
end
end

def self.down
drop_table :cds
end
end

Et pour finir nous allons dire à notre application qu’il faut « migrer » c’est à dire changer de version (ou encore exécuter 001_create_cds.rb), toujours dans votre console à la racine de votre application tappez :

rake db:migrate

Et la magie va s’opérer : la table « cds » va être crée automatiquement dans MySQL, concrètement ce qui se passe c’est que la commande rake db:migrate si elle est appelée sans paramètre va invoquer les méthodes self.up de chaque classe de Migration (chaque fichier du répertoire db/migrate/). En spécifiant un paramètre comme le numéro de la migration vers laquelle nous voulons aller, Rails fera en sorte de revenir à la version demandée en invoquant les méthodes self.down impliquées… subtil mécanisme, peut être pas évident à saisir dans un premier temps mais terriblement efficace !

Prenons un example, la spécification faites en début de projet d’un CD ne me plaît plus, il me manque des informations cruciales telles que l’année de parution ou encore la date d’achat si je veux garder un historique des achats de mes CDs… Nous allons créer une nouvelle « migration » pour notre modèle :

script/generate migration add_some_dates

Le script génère le fichier db/migrate/002_add_some_dates.rb qu’il ne nous reste plus qu’a compléter avec les instruction d’ajout de colonne en self.up et les instruction de suppression de colonne en self.down :

class AddSomeDates < ActiveRecord::Migration
def self.up
add_column :cds, :year, :integer
add_column :cds, :buy_date, :datetime
end

def self.down
remove_column :cds, :year
remove_column :cds, :buy_date
end
end

Il suffit d’exécuter à nouveau :

rake db:migrate

pour mettre la base de donnée à jour avec les nouvelles informations…

Maintenant que je vous ai mis l’eau à la bouche avec ces premières ligne de code, passons à la vitesse supérieure !

Génération automatique de l’application !

Vous avez bien lu le titre… et si vous vous intéressez un tant soi peu à Rails vous avez du voir quelques démos et vous savez que c’est possible… mais comment ? Nous allons le voir maintenant.

La génération automatique de l’application (mécanisme appelé scaffold) s’appuie sur votre modèle pour générer les méthodes du contrôleur et la (ou les) vue(s) dynamiquement. En utilisant cette méthode nous n’abordons pas l’écriture complète d’un « controller » et d’une « view ». (Parcequ’il est intéressant de voir ce mécanisme de scaffold mais aussi parcequ’il ne faut pas perdre de vue l’aspect « VC » du MVC nous y reviendrons plus en détail par la suite.)

Scaffold…

Le scaffold s’appuie donc sur un modèle. En fait le principe est d’indiquer dans le fichier du contrôleur quel est le nom de notre modèle. Il faut donc commencer par générer un contôleur pour nos CDs que nous appellerons simplement « cd » :

script/generate controler cd

Encore une fois Rails va créer 3 nouveaux fichier dont app/controllers/cd_controller.rb qui nous intéresse. C’est dans ce fichier (notre contrôleur) que nous allons « décrire » le scaffold. Cela se fait de la manière suivante :

class CdController < ApplicationController
scaffold :cd
end

Et c’est fini ! En fait la ligne « scaffold :cd » indique au contrôleur CdController d’utiliser le modèle « cd ».
Il vous suffit ensuite de vous rendre sur votre site : http://localhost:3000/cd… et si la magie à bien opéré vous pourrez dès à présent voir votre liste de CD, en ajouter, en supprimer ou encore en éditer !

Bon alors c’est bien beau mais… jusque là, on a écrit aucune ligne de code (ou presque) pour faire tout ça. Alors, comment va t’on faire pour pouvoir modifier cette petite application ?

Nous allons simplement dire à Rails de générer le code une bonne fois pour toute au lieu de le générer dynamiquement à chaque appel…

Générer le code correspondant au scaffold !

Je ne dirai qu’une seule chose :

script/generate scaffold cd cd

Notre contrôleur portant le même nom que notre modèle, la syntaxe peut paraître floue. La voila en plus clair :

script/generate scaffold ModelName ControllerName

La commande devrait vous demander de remplacer des fichiers existant, il faut bien entendu confirmer. Ceci fait, si vous vous rendez à l’adresse http://localhost:3000/cd vous verrez que rien n’a changé. Pourtant tout le code a été généré, pour vous en rendre compte éditer votre contrôleur (app/controllers/cd_controller.rb).

class CdController ‘list’
end
…

Et oui ! Il est tout plein de méthodes pour ajouter, supprimer, éditer ou encore lister vos CD… Vous pouvez vous attarder un peu sur ce fichier et essayer d’en lire le code. Même si il ne vous parle pas trop, cela vous habituera un peu à la syntaxe. Ruby (et donc Rails) est connu pour être un code relativement facile à lire.

Tant que vous y êtes, faites un petit tour dans les autres répertoires, notamment celui des vues (app/views). Vous verrez que les vues sont en fait les fichiers contenant le code HTML servant à la présentation des informations. Le répertoire app/views/cd contient toutes les vues concernant le contrôleur « cd », le répertoire app/views/layout contient lui des « patrons de présentation ». En fait une vue sera affichée à l’intérieur d’un layout. Un layout peut donc être utilisé pour concevoir la structure d’affichage des informations.

Dans notre exemple, le layout cd.rhtml est utilisé par toutes les vues. Ce comportement est automatique car le layout porte le nom du contrôleur, mais attention ce comportement n’est pas non plus rigide, il est possible d’indiquer à un contrôleur d’utiliser un layout différent que celui par défaut. C’est utile par exemple lorsque l’ensemble de notre application doit être présenté de la même façon. C’est le cas par exemple d’une grande partie des sites Internet qui quels que soit la page garde toujours une structure avec un bandeau, un menu et un contenu…

Avant d’aller plus loin nous allons régler un « pseudo » problème : l’erreur sur la page d’accueil. Maintenant que nous avons un semblant d’application, ce serait pas mal que lorsqu’on appelle directement notre site (http://localhost:3000) la liste des CDs arrive en page d’accueil.
Ceci peut être résolu par les routes. Editez donc le fichier config/routes.rb :

Décommentez la ligne suivante :

map.connect  », :controller => « welcome »

et modifier la comme suit :

map.connect  », :controller => « cd »

En vous rendant sur http://localhost:3000 vous devriez normalement accéder directement à votre application. Ce fichier routes.rb permet de définir des « routes » pour votre application, je n’en dirai pas plus pour l’instant et je vous invite à lire les commentaires de ce fichier pour en apprendre un peu plus.

Je veux des commentaires !

Sur l’application de gestion de CDs… les commentaires. Pas sur mon article ! Quoique…

Bref, que serait une application moderne sans la possibilité pour les utilisateurs de commenter tout ce qu’ils cliquent ? … D’accord, d’accord… le but de l’article n’est pas de faire du web2 mais bon, tant qu’a faire, on utilise un langage qui fait « class » alors pourquoi ne pas y ajouter quelques petites fonctionnalités de ce qu’on appelle plus sérieusement le « user generated content » !

Nous aborderons donc dans cette partie la création du modèle « comment », son lien avec le modèle « cd », la modification du contrôleur CD et des vues existantes, et enfin nous verrons comment ajouter une pincée d’Ajax dans la machine…

Le modèle commentaire.

script/generate model comment

Nous nous arrêterons là pour les générations ce coup ci. Le reste sera fait à la mano

Commençons par décrire notre table commentaire dans le fichier de migration (db/migrate/003_create_comments.rb)

class CreateComments false
end
end

def self.down
drop_table :comments
end
end

Notez qu’il est nécessaire d’indiquer le nom de la colonne qui servira à faire la relation entre les commentaires et les CDs ( :cd_id ).

rake db:migrate

Et votre table sera crée !

Lien avec le modèle CD

Il faut maintenant indiquer à notre application qu’il existe un lien entre les tables « cd » et « commentaires ». Ce lien sera indiqué dans les modèles respectifs :

(app/models/cd.rb)

class Cd :destroy
end

On indique ici qu’un Cd « a beaucoup » de commentaires et aussi que si on supprime un Cd, alors les commentaires associés seront aussi supprimés ! (merci Rénald.)
Cette dépendance est ici spécifiée sur la couche application, on pourrait aussi l’ajouter au niveau des données (MySQL) à travers une relation (FOREIGN KEY / ON DELETE CASCADE) pour être certain de l’intégrité des données lors de la suppression.

(app/models/comment.rb)

class Comment < ActiveRecord::Base
belongs_to :cd
end

Et ici on dit qu’un commentaire « appartient à » un CD !

Notre application sait maintenant qu’une relation de type 0..N uni nos 2 tables.

Listing et formulaire de création de commentaire :

Les commentaires et leur formulaire d’ajout se trouvent classiquement sur la fiche CD, éditons donc la vue correspondante (app/views/cd/show.rhtml) et ajoutons y nos 2 parties :

Fiche CD

Contenu

:

‘edit’, :id => @cd %> |
‘list’ %>

Commentaires

-

Ajouter un commentaire :

« add_comment », :id=>@cd %>
Auteur :
Email :

On a donc une boucle « for » qui parcours le contenu des commentaires associés au CD en cours (@cd.comments). Pour réaliser le formulaire on utilise des « helpers », ce sont des méthodes qui nous aide à générer le code HTML correspondant. Par exemple le helper « form_tag » envoie les résultats du formulaire sur l’action « add_comment » du contrôleur « cd » en lui passant comme paramètre le CD en cours.

C’est bien beau d’avoir le formulaire mais il nous faut maintenant écrire une méthode pour pouvoir enregistrer un commentaire, pour cela nous allons éditer le fichier app/controller/cd_controller.rb et ajouter la méthode add_comment :

class CdController « show », :id => params[:id]
end
end

Cette méthode reçoit donc les résultats du formulaire. « Cd.find(params[:id]) » accède à l’objet CD dont l’id a été envoyé, « comments » accède à la collection de commentaires de cet objet CD et « create » réalise une action sur cette collection en y ajoutant l’objet « :comment » reçu par en paramètre. Enfin la méthode add_comment nous renvoie sur la méthode « show » avec l’id en cours afin de re-afficher la fiche CD.

Quelques vérifications…

Ou plutôt devrais-je dire « validations »… En effet nous allons vérifier que les informations saisie à travers les formulaires sont bien celles que nous attendons. Pour cela Rails nous fournit un mécanisme très performant de validations.

Reprenons un instant le formulaire d’ajout de CDs, il serait intéressant de vérifier lors d’un ajout que les champs Titre et Auteurs soient systématiquement présents. Pour faire cela éditons le fichier app/models/cd.rb comme ci dessous :

class Cd < ActiveRecord::Base
has_many :comments
validates_presence_of :title, :author
end

… et la pincée d’Ajax !

Personnellement, j’aime lorsque Ajax est utilisé à bon escient, on peut dire alors qu’il est non intrusif pour l’utilisateur. Ainsi en général je me fixe comme règle d’utiliser ajax que si cela apporte un réel plus à l’utilisateur. Dans tous les cas il faut qu’un visiteur sans Javascript puisse quand même effectuer l’action demandée.

Sachant cela, nous pouvons nous lancer. Nous allons permettre à nos visiteurs de publier un commentaire sans impliquer le rechargement total de la page, c’est presque inutile/intrusif mais c’est pour l’exemple (J’avais promis qu’on aurait un peu d’ajax dans notre première appli Rails !)

Il faut d’abord commencer par alléger un peu notre fichier affichant le CD et les commentaires. Pour cela nous allons utiliser le système des « partial ». Ces partial sont en fait des vues partielles, ainsi cela nous permettra de mettre ce qui concerne l’affichage d’un seul commentaire dans un fichier à part et de l’inclure dans notre fichier principal.

Créons donc notre fichier app/views/cd/comment.rhtml (le «  » a son importance !) et mettons y ce qui concerne notre commentaire (ce qu’il y avait donc dans la boucle for de la page show.rhtml)

-

Ainsi notre fichier app/views/cd/show.rhtml devient (dans la partie concernant les commentaires) :

…

Commentaires

Ajouter un commentaire :

…

Le partial « _comment.rhtml » sera donc appelé pour chaque occurrence de la collection « @cd.comments » en mettant le résultat dans une variable du nom du partial (comment).
Intéressons nous maintenant au formulaire d’ajout de commentaire. Il faut lui dire d’envoyer ses données grâce à l’objet XmlHttpRequest, cela se fait de façon transparente de cette manière :

Ajouter un commentaire :

{:controller=> :cd, :action => :add_comment, :id => @cd }, :update => ‘comments’, :position=> :bottom) %>
Auteur :
Email :
60, « rows » => 5 %>

Le helper form_remote_tag va envoyer les résultats du formulaires sur la même action (:add_comment), lorsque le formulaire sera exécuté l’élément ‘comments’ sera mis à jour en insérant le contenu mis à jour en bas (:position=> :bottom).

Avant de tester il va falloir modifier un peu la méthode :add_comment afin qu’elle gère correctement notre formulaire Ajax :

def add_comment
@comment=Cd.find(params[:id]).comments.create(params[:comment])
if request.xhr?
render (:partial => « comment », :locals => { :comment => @comment } )
else
redirect_to :action => « show », :id => params[:id]
end
end

Le test request.xhr vérifie si notre requête a été transmise par l’objet XmlHttpRequest ou de façon plus classique, dans le cas d’un fonctionnement Ajax nous indiquons de n’afficher que le partial, dans le cas contraire toute l’action « show » est exécutée.

Update : Enfin pour que le javascript fonctionne correctement il faut ajouter au fichier app/views/layouts/cd.rhtml la ligne suivante entre les balises head :

…

Passage en production.

Considérons notre application comme terminée. Elle est certe moche et sans intérêt majeur mais mettons nous dans l’optique de la publier sur un hébergement Rails. Avant d’entamer les recherches pour un hébergeur nous allons passer en mode « production ». Ce mode doit être utilisé lorsque l’application est terminée.

Il faut donc définir la configuration du mode production dans le fichier de base de donnée (config/database.yml) :

production:
adapter: mysql
database: mescds
username: user
password: password
host: localhost

Enfin il faut changer le mode actif dans le fichier « config/environment.rb », pour cela il suffit de décommenter la 5ème ligne :

ENV['RAILS_ENV'] ||= ‘production’

Normalement il faudrait redémarrer le serveur, mais sur votre environnement cela ne sert à rien il me semble car Rails force le mode « development ». Ce n’est pas grave, les fichiers sont prêts à être envoyer en ligne…

Mise en Ligne !

Changement de dernière minute

Cette partie devait être l’une des plus intéressante de ce billet car c’est un sujet peu abordé dans le monde « Rails » où les hébergeurs ne sont pas encore très nombreux mais voilà… j’avais prévu de faire cette partie avec HostingRails qui proposait un hébergement gratuit mais apparemment c’est fini, ils ne proposent plus de formule gratuite… (C’est tout récent, quand j’ai commencé l’écriture de ce billet il ya plusieurs jours cela existait encore…)

Ils ont quand même des offres à bas prix (ça doit démarrer à un peu moins de $4 par mois…) et ayant toujours un hébergement chez eux (ils n’ont quand même pas supprimer les comptes existants !), si ça intéresse des gens que je publie comment faire pour mettre en ligne l’application, je le ferai avec plaisir.

En attendant si vous avez une dédibox ou un serveur dédié, vous pouvez toujours lire cet autre billet qui vous expliquera comment mettre en place un hébergement Rails digne d’un serveur de production, depuis l’installation jusqu’au déploiement de l’application grâce à Capistrano.

Hébergement Dreamhost

Pour ceux qui sont intéressés par un hébergement un peu plus professionnel avec une architecture proche de celle que j’ai déployée sur ma dédibox, je vous conseille d’aller voir chez Dreamhost. Pour $9.95 par mois, vous aurez accès à plus de 200Go d’espace disque, 1 To de transfert/mois, base mysql illimitées, 3000 comptes mails et 75 users SSH/FTP. Vous pourrez alors faire du RubyOnRails mais aussi du PHP4 ou PHP5, vous pourrez utiliser un serveur de versionning (Subversion), vous pourrez même déployer votre application en utilisant Capistrano !

Le prix tombe à $7.95/mois si l’on paye pour 2 ans, mais ce n’est pas tout, avec cet hébergement vous avez un nom de domaine offert et vous pourrez rapidement déployer votre propre blog WordPress (comme le mien) !
Enfin, vu que j’ai déjà un hébergement là-bas, je peux vous faire profiter d’une ristourne de $50 sur votre achat en saisissant ce code promo en bas de page : STONEAGECODE.

Pour aller plus loin …

Je conseille vivement la lecture du livre « Agile Web Development With Rails » qui présente la création d’une boutique de ecommerce en Rails de façon très didactique.

et enfin pour aller encore plus loin …

Update 05/06/07 : Je viens d’écrire un nouvel article sur comment faire un nuage de tag avec ruby on rails, il fait suite à cet article et reprend le même exemple.