Olivier El Mekki

Installation de ruby on rails pour designers

Vous êtes designer, et on vous a demandé de travailler sur un projet Ruby On Rails. Vous télécharger le code de l’application et là, aïe aïe aïe, qu’est-ce que c’est que tout ça?

Ruby On Rails est un framework, ce qui implique une grosse infrastructure présente par défaut. De plus, le code est éclaté du fait de la séparation MVC. Cela, c’est la première bonne nouvelle pour vous, designers. Le seul endroit où vous devez agir est dans les vues, et dans le CSS. Mais revenons pas à pas sur le processus d’installation.

Cet article se concentre sur l’installation pour Windows, étant donné que c’est encore le système le plus courant. Si vous utilisez un système libre, il vous suffira de passer par votre gestionnaire de paquet. Si vous utilisez MacOSX, je ne peux vous dire où télécharger le nécessaire, mais il ne devrait pas y avoir de changements majeurs.

Installation du nécessaire

Ruby on Rails, comme son nom l’indique, est un framework utilisant le langage Ruby. Il vous faut donc, dans un premier temps, installer l’interpréteur de ce langage. Il existe un installeur pour ça. Lorsque vous l’installez, prenez bien soin de laisser l’option cochée par défaut qui propose d’installer RubyGem.

Gem est un gestionnaire de paquet pour ruby. Cela signifie que par son intermédiaire, vous pouvez installer, supprimer et mettre à jour des libraries ruby (Gem ira les chercher de lui-même sur le net). Rails fait partie de ces libraries.

Pour installer rails, ouvrez une invite de commande MS-DOS. Il faut d’abord mettre à jour la liste des paquets de gem, puis installer rails lui même, en lançant ces deux commandes successives :

gem update --system
gem install rails --include-dependencies

Ensuite, vous devez installer le moteur de base de donnée utilisé pour votre projet. Le plus courant est MySQL. Rails propose aujourd’hui par défaut l’utilisation de SQLite3, mais bien que ce soit une base de donnée que j’apprécie beaucoup, la library Rails qui en permet l’utilisation m’a causé de nombreux problèmes. Je vous conseille donc d’utiliser MySQL à la place (si néanmoins vos développeurs utilisent sqlite, son installation ne vous posera pas de problème, interrogez vos développeurs au cas où).

Téléchargez l’installeur de MySQL et suivez ses instructions. Vous pouvez accepter la plupart des choix par défaut, si ce n’est le charset par défaut. Demandez à vos développeurs quel charset ils utilisent, il y a de grandes chances pour qu’ils vous répondent : UTF-8. Dans ce cas, au moment du choix du charset, choisissez : Best Support For Multilinguism. Assurez-vous également, dans la fenêtre suivante, de cocher : Include BIN directory in Windows PATH.

Il ne reste plus qu’à installer l’application rails en elle-même. Les développeurs avec lesquels vous travaillerez utiliseront probablement SVN pour synchroniser votre travail commun. TortoiseSVN vous permettra de facilement utiliser ce protocole. Un peu de vocabulaire pour vous aider à vous y retrouver:

Configuration

Lors de cette étape, il s’agit surtout de configurer la base de donnée. Si vos développeurs sont gentils, il vous auront fourni un fichier de configuration standard que vous pourrez adapter. Si ce n’est pas le cas, je vais vous en donner un.

Mais d’abord, il faut bien saisir qu’il existe, dans Rails, trois environnements : l’environnement de développement, l’environnement de production et l’environnement de test. Du point de vue du designer, vous ne vous servirez que du premier. C’est l’environnement classiquement utilisé pendant la conception d’une application. Lorsque l’application est publiée, on la place en environnement de production, ce qui joue principalement sur le fait que beaucoup plus d’éléments sont mis en cache. Cela permet d’aller plus vite, mais le caching, de par sa nature, pose des problèmes ennuyeux lorsqu’on fait de nombreuses et régulières modifications. L’environnement de test, quant à lui, ne sert qu’aux tests automatisés et n’ai pas utilisé manuellement.

Si j’insiste sur la distinction entre ces trois environnements, c’est que chacun possède sa propre base de donnée. Ainsi, un fichier de configuration standard pour MySQL sur Windows ressemble à ceci (notez que sur un système à base Unix, vous pouvez, pour augmenter la vitesse, utiliser le fichier de socket de mysql plutôt que de vous connecter à localhost) :

development:
  adapter: mysql
  encoding: utf8
  host: localhost
  database: projet_dev
  username: nom
  password: password

test:
  adapter: mysql
  encoding: utf8
  host: localhost
  database: projet_test
  username: nom
  password: password

production:
  adapter: mysql
  encoding: utf8
  host: localhost
  database: projet_prod
  username: nom
  password: password

N’ayant pas besoin du second et du troisième environnement, vous pouvez très bien omettre leur description. Placez ces informations dans un fichier nommé database.yml et rangez ce fichier dans config/ dans le répertoire de votre application rails.

Il faut ensuite créer les bases de données. Ouvrez une invite de commande MS-DOS et tapez dedans (en remplaçant le nom de votre projet, le nom de votre utilisateur et le mot de passe) :

mysql

Renseignez votre mot de passe, puis :

CREATE DATABASE <strong>projet_dev</strong> ;
GRANT ALL ON <strong>projet_dev</strong>.* TO '<strong>nom</strong>'@'localhost' IDENTIFIED BY '<strong>password</strong>' ;

Répétez cela avec projet_test et projet_prod si vraiment vous en avez besoin.

La base de donnée est maintenant créée, il reste une dernière fois à mettre les mains dans le cambouis pour créer sa structure (promis après, c’est fini). Avec votre invite de commande, rendez-vous dans le répertoire de l’application et tapez :

rake db:migrate

Cela créera automatiquement cette structure. Si vos développeurs ont vraiment été très gentils (mais ne rêvons pas, ce sont des développeurs), cette commande peuple même la db avec des données utilisables (en créant des utilisateurs, des produits, etc).

La configuration est maintenant terminée. Vous pouvez démarrer l’application en utilisant le serveur intégré de rails (où peut-être voulez-vous que nous voyions rapidement la configuration d’apache? ;) ). Toujours dans le répertoire principal de l’application, dans l’invite de commande, tapez :

ruby script/server

Il ne vous reste plus maintenant qu’à vous rendre à l’adresse http://127.0.0.1:3000 . Tapez control-c dans l’invite de commande pour arrêter le serveur. Ce serveur est particulièrement lent et ne peut donc être utilisé en production, mais il a le mérite de permettre de tester rapidement une application.

Explication de l’architecture

Ruby on Rails est un framework reposant sur le MVC : Models, Views, Controllers. Cela signifie qu’il y a une distinction fondamentale entre ce qui relève de la gestion des entités (les modèles, la plupart du temps mappés sur des tables de la base de donnée), des actions exécutables par l’utilisateur (les contrôleurs) et du contenu renvoyé en échange (les vues).

Ce qui vous intéresse, en tant que designer ou frontend developer, ce sont ces vues. C’est là que résident les fichiers .html (ou plutôt, les fichiers html.erb, je vais revenir là dessus). Les models, views et controllers se trouvent dans le répertoire app/ .

Probablement encore plus important pour vous est le répertoire public/ . C’est en fait le seul répertoire visible de l’extérieur. Vous pourrez y placer vos fichiers CSS, javascript, audio, images et autres.

Et c’est à peu prêt tout ce que vous avez besoin de savoir sur l’architecture d’une application rails pour pouvoir travailler avec.

Je n’ai encore jamais rien vu dans le dossier doc/, mais si vos développeurs sont les nouveaux messies sur Terre, ils y auront placé toute sorte d’informations intéressantes. Les noms des dossiers config/ et log/ parlent d’eux-même. lib/ et vendor/ servent à placer des bouts de codes des plus utiles, db/ est le répertoire où l’on place les migrations, qui ont permis la création quasi-magique de la base de donnée tout à l’heure. script/ contient quelques utilités comme le serveur, et beaucoup de petits scripts facilitant la vie des développeurs. test/ est le répertoire où se trouvent les tests automatisés (et si vous voulez embêter vos développeurs, demandez leur pourquoi les fichiers dans test/functionals et test/units ont si peu de lignes). Enfin, Rakefile est un fichier permettant d’autres tours de magie de rails, tellement nombreux que je ne m’amuserai pas à les énumérer :) (ah, si : dans une invite de commande, tapez “rake stats” et demandez à vos développeurs comment il se fait que le Code to test ratio a une valeur si faible côté test).

html.erb ?

Vous vous êtes probablement déjà retrouvé confronté à du code PHP que vous avez dû tenter tant bien que mal de comprendre pour avoir une idée d’où placer vos id et vos class ( “mais d’où vient ce div?” ).

Du fait de la séparation MVC, cela est moins problématique en rails, mais il y a tout de même besoin de rajouter un peu de code dans le HTML. Le langage utilisé est Ruby. Si vos développeurs ont bien fait leur travail (je vais vraiment tous me les mettre à dos), ce code doit être parfaitement compréhensible, même si vous ne connaissez absolument pas Ruby.

La forme standard pour exécuter du code Ruby dans un template erb est :

< % code %>

Il y a néanmoins plusieurs variantes. La balise que je viens de vous montrer n’affiche normalement rien en sortie dans le HTML, sauf si une fonction le demande explicitement (ce qui doit normalement être évité, au profit de la balise suivante). Pour afficher du code, on utilise : <%= %>. Vous verrez ainsi souvent :

< %= @var %>

Cela signifie simplement qu’il faut écrire le contenu de la variable @var. Un autre modificateur est le signe moins ( - ) avant la fermeture de la balise, comme ceci :

<p>Nom: < %= @user.name -%></p>

Cela permet un formatage plus propre du code HTML : un balise sans “-” retourne à la ligne, une balise avec, non.

Le type de code le plus “complexe” que vous devrez voir est comme ceci :

<!-- exemple 1 -->
< % if @user.logged? %>
  <p>Salut < %= @user.name -%></p>
< % end %>
 
<!-- exemple 2 -->
<ul id"product_list">
< % @products.each do |prod| %>
   <li>< %= prod.name -%></li>
< % end %>
</ul>
 
<!-- exemple 3 -->
< % form_for :vote, @vote do |f| %>
  <p>< %= f.label :rate, "Rate this" -%> < %= f.rate_radio :rate -%></p>
  <p>< %= f.label :username, "Your name" -%> < %= f.text_field :username -%></p>
  <p>< %= f.submit -%></p>
< % end %>

L’exemple 1 est parfaitement compréhensible pour qui ne connaît pas Ruby, pour peu qu’on sache que if en anglais signifie si (condition). Si l’utilisateur est loggé, dire : salut son_nom.

L’exemple 2 se comprend très bien aussi, dès lors qu’on sait que each signifie chacun : pour chaque produit, écrire un li avec son nom.

Le troisième exemple est plus problématique. C’est un vrai plaisir pour nous les développeurs, mais ça peut être très ennuyeux pour les designers. Je ne doute pas que vous compreniez ce qu’il fait : il s’agit de créer un formulaire. En fait, cela fait bien mieux : cela crée un formulaire en se basant sur un modèle de la base de donnée et en facilitant son interprétation à l’envoi (un autre tour de magie de rails). Le vrai problème pour un designer est que si vous voulez rajouter une class ou un id aux éléments générés ainsi, vous devrez probablement demander à un développeur de le faire (mince, vous n’auriez peut-être pas dû leur poser toutes ces questions sur les tests :] ).

Ce type de fonction est ce qu’on appelle des helpers, et ils nous sont effectivement, à nous, d’une grande aide pour accélérer le développement. Rassurez-vous cependant : j’ai pris un exemple extrême, et vous ne devrez pas être ennuyés plus que cela par eux. En fait, vous retrouverez la plupart du temps les même, et vous saurez vite les modifier vous même. (mais bon, si les développeurs avaient bien fait leur boulot, vous n’auriez pas à les modifier…).

Conclusion

Je conclurai qu’il était vraiment temps de conclure. Oui, le premier contact avec ruby On Rails peut être un peu refroidissant, vis-à-vis du travail à faire pour le mettre en place, mais ce n’est pas peine perdue, vous en serez tout à fait satisfait (parole de développeur). Contrairement à ce que peut laisser penser l’installation, Ruby On Rails a été pensé pour tout accélérer.

Dans ce contexte d’effervecence de la production, vous apprécierez que chacun ait sa partie de l’application consacrée, ce qui permet de limiter les conflits de version svn. En plus comme ça, vous aurez moins à parler aux… Bon d’accord, j’arrête. :]

3 Réponses à “Installation de ruby on rails pour designers”

  1. digg-design.fr dit:
    9 octobre, 2008 à 11:00

    Installation de ruby on rails pour designers…

    Vous êtes designer, et on vous a demandé de travailler sur un projet Ruby On Rails. Vous télécharger le code de l’application et là, aïe aïe aïe, qu’est-ce que c’est que tout ça? Suivez le guide….

  2. Alexandre dit:
    29 mars, 2010 à 20:09

    Merci.

    Un designer qui vient de mettre le nez dans Rails.

  3. kik dit:
    3 avril, 2010 à 14:50

    Heureux que ça t’ait servi :)

Laisser un commentaire