Archives par étiquette : pibou

Node.js & express.js for noob, premiers pas

Bien le bonjoir, je vous propose que nous découvrions nodejs ensemble. Pour ce faire, je vais reprendre le principe de Pibou en utilisant nodejs pour exposer une api que je pourrais attaquer avec différentes technologies front et/ou mobile. Mais pour commencer, parlons un peu de Node.js node_home_install

C’est quoi ?

Node.js is a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

Pour résumer, Node.js est un wrapper autour du moteur de javascript V8 qui permet de coder du bas niveau du côté serveur en Javascript.

Événementiel et non bloquant

La programmation est orientée événementielle: chaque action possède une fonction de rappel. Contrairement à d’autres technologies, la boucle de gestion des événements est transparente pour l’utilisateur, c’est le côté non bloquant. Concrètement, si vous lancez l’exécution de plusieurs actions, elles seront traitées en parallèle, sans attendre que la précédente ait appelé sa fonction de rappel.

Écosystème

Nodejs c’est aussi tout un ensemble d’outils. La philosophie peut se résumer à « vous avez un besoin, il y a un module pour ça ». C’est bien beau me direz-vous, mais comment gérer cette foison de modules? C’est là qu’intervient NPM, le node package manager. Il est très utile pour gérer vos modules. Il existe une multitude de modules, nous en reparlerons au fur et à mesure.

Installation

Pour commencer, il faut installer node.js sur votre machine, il y a tout ce qu’il faut sur http://nodejs.org/ Nous pourrions tout coder directement, mais je préfère utiliser un module qui nous facilitera la tâche : express.js. Pour installer express globalement, nous allons nous servir de npm (installé avec node)  :

npm install express -g

Voilà, il ne reste plus qu’a utiliser la génération d’express pour avoir un aperçu de notre structure de projet.

express pibou-node

Regardons ce que ça donne :

sortie console de la commande express pibou-node

sortie console de la commande express pibou-node

Suivons les instructions, d’abord aller à la racine du projet

cd pibou-node

Puis installer les dépendances :

npm install

Puis, lancer l’application :

node app

La console nous informe que le server est lancé : server_started Il n’y a plus qu’a ouvrir un navigateur : express_default Et côté serveur : first_responses   Voilà, on a un serveur qui tourne et qui rend une page. Bon, c’est un peu « magique » pour le moment, allons jeter un œil sur le code généré.

La structure du projet

La configuration

Le fichier package.json représente la configuration du projet. Nous allons juste donner un nom et une version à notre projet, ce qui nous donne :

{
  "name": "pibou-node",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "node app.js"
  },
  "dependencies": {
    "express": "3.4.x",
    "jade": "*"
  }
}

Je vous conseille de faire un tour sur http://package.json.nodejitsu.com/, c’est une très bonne documentation dynamique pour la configuration. Pour savoir quelles sont les dépendances et leur version, vérifier les packages sur https://www.npmjs.org/.

L’application

On peut voir dans la configuration que le lancement de l’application se fait par la commande « node app.js », on peut en déduire que la racine du projet est dans le fichier app.js. Décortiquons son contenu :

/**
 * Module dependencies.
 */

var express = require('express');
var routes = require('./routes');
var user = require('./routes/user');
var http = require('http');
var path = require('path');

var app = express();

// all environments
app.set('port', process.env.PORT || 3000);
app.set('views', path.join(__dirname, 'views'));
app.set('view engine', 'jade');
app.use(express.favicon());
app.use(express.logger('dev'));
app.use(express.json());
app.use(express.urlencoded());
app.use(express.methodOverride());
app.use(app.router);
app.use(express.static(path.join(__dirname, 'public')));

// development only
if ('development' == app.get('env')) {
  app.use(express.errorHandler());
}

app.get('/', routes.index);
app.get('/users', user.list);

http.createServer(app).listen(app.get('port'), function(){
  console.log('Express server listening on port ' + app.get('port'));
});

La première partie liste les dépendances vers des modules de la bibliothèque ou vers les méthodes exposées dans l’application. On retrouve les modules importés via le package.json dans le dossier pibou-node/node_modules. Vient ensuite la configuration du serveur et les éléments à utiliser.  On voit qu’on utilise le moteur de templating jade pour les vues qui sont référencées dans le répertoire pibou-node/views. Vous pouvez choisir le moteur qui vous fait plaisir, il se trouve que Express.js propose jade par défaut. Cela vous permet de générer votre réponse au format html (ou autre format à la sauce xml). Express fourni un ensemble d’outil (log, middleware, traitement du json) qui sont bien pratiques. Je vous encourage vivement à faire un tour sur la documentation d’api et le guide d’express.js

Le Routing

Le mécanisme de routing est proche de ce que vous pouvez trouver avec rails. Vous déclarez un path et vous pouvez y lier une méthode. Prenons un cas concret :

var user = require('./routes/user');
//...
app.get('/users', user.list);

Vous dites que vous allez appeler la méthode ‘list’ exportée de pibou-node/routes/user.js. Si on regarde le fichier user.js ;

/*
 * GET users listing.
 */

exports.list = function(req, res){
  res.send("respond with a resource");
};

Le « exports. » est utilisé pour exporter la méthode, la rendre visible par require. La fonction se contente de répondre avec le texte « respond with a resource » sur une requête en get sur l’url http://localhost:3000/users.

Le templating

Nous avons parlé de jade, nous pouvons voir son utilisation dans le fichier routes/index.js.

/*
 * GET home page.
 */

exports.index = function(req, res){
  res.render('index', { title: 'Express' });
};

C’est la partie render qui va appeler la vue correspondante, ici ça sera pibou-node/views/index.jade et lui passer un objet { title: ‘Express’ }. C’est la configuration dans pibou-node/app.js qui a défini pibou-node/views comme répertoire de référence pour les templates. L’appel à render précise de récupérer le fichier pibou-node/views/index dont l’extension est déterminée par le moteur de templating choisi, « .jade » dans notre cas. Allons regarder ce fichier de template :

extends layout

block content
  h1= title
  p Welcome to #{title}

Le vous laisse lire la documentation pour la syntaxe. Le fichier défini une structure html et utilise une variable pour rendre le titre. Nous avons vu qu’il suffit de passer un objet avec les propriétés attendues pour qu’il soit utilisable dans le template. En ce qui concerne le layout, si on suit la logique précédente, il suffit d’ouvrir le fichier /views/layout.jade :

doctype html
html
  head
    title= title
    link(rel='stylesheet', href='/stylesheets/style.css')
  body
    block content

Il s’agit tout simplement de la structure de base d’une page html qui référence une CSS de base.

Et la suite ?

Je vous laisse découvrir ces technologies, générer votre projet et explorer la configuration du package.json. Notre prochaine étape nous fera manipuler le code et découvrir de nouveaux modules. @Bientôt

Références

Tester, tout un art

Bien le bonjour. Aujourd’hui, nous allons aborder la partie tests d’une application. Je pensais attaquer directement sur des exemples de tests appliqués à Pibou mais nous allons d’abords discuter  de façon plus générale.

Pourquoi tester ?

L’utilité des tests est un grand sujet de débat. Pour ma part ils servent pour plusieurs choses :

Le design

La réalisation de tests aide à structurer son code. Ceci pour plusieurs raisons :

  • Les tests nécessitent une réflexion sur la façon de découpler son code.
  • Les tests mettent en pratique votre pensée et les concepts que vous voulez implémenter. C’est du « code d’intention », votre design va évoluer au fur et à mesure que vous allez le mettre en pratique dans le contexte d’utilisation.
  • Dans une logique de TDD (voir chapitre suivant), ils vont peu à peu changer votre façon d’aborder le développement.

La validation des fonctionnalités

Les tests sont à la fois l’expression des besoins fonctionnels et celle du comportement de votre code.
Il va permettre de valider ce qu’attend l’utilisateur mais également fixer le comportement, c’est une forme de spécification via des cas d’utilisations.

Le filet de sécurité

Les tests sont également là pour s’assurer de la non régression. Cette sécurité améliore les conditions de développement pour la maintenance, l’évolution et le refactoring du code. Combien de fois avez vous évité une refonte car vous n’étiez pas sûr de ne pas ‘casser’ quelque chose ? 😉

La documentation

Contrairement à une documentation « classique »  (type javadoc, wiki, doc, etc..), votre code se doit d’être à jour pour fonctionner.
L’écriture des tests nous indique comment le code doit se comporter mais également l’approche des personnes qui l’ont écrit. Les cas d’utilisation et les limites.

L’apprentissage

Si vous découvrez une nouvelle API ou un nouveau framework, l’utilisation de tests pour comprendre et découvrir est une excellente approche. Non seulement les tests mettront en évidence le comportement mais ils permettront également de fixer ce que vous attendez. Si le framework ou l’API évoluent, ces tests vous montrerons les changements qui impactent votre utilisation.

Un petit mot sur le TDD

Le Test Driven Development est une approche qui prône pour l’écriture des tests avant le code de production mais pas que. On peut le résumer par un cycle de développement tel que:

  1. Ecrire un test pour valider une fonctionnalité ciblé du code
  2. Faire échouer le test
  3. Ecrire le code de production qui répond à ce test
  4. Faire réussir le test
  5. Refactorer son code chaque fois que nécessaire à partir d’une suite de tests valide
Il s’agit de cycles courts qui doivent cibler des parties spécifiques du code. C’est un développement itératif et incrémental où chaque étape est une  évolution stable du code en fonction des besoins.

Les types de tests

  • Il y a les tests unitaires qui sont des tests en isolation. Il servent à tester spécifiquement des parties du code ‘de façon unitaire’.
  • Les tests d’intégration testent le comportement plus global de l’application. Il vérifient  les liens entre les différentes parties du code.
  • On parle parfois de test d’intégration pour les tests d’interface graphique. Il s’agit dans la plupart des cas de framework qui permettent de simuler des actions utilisateurs (click, changement de pages, remplissage de formulaires)
  • Il y a les tests fonctionnels qui sont la vérification du besoin métier. Ces tests sont plus souvent écrit dans un langage proche du métier et peuvent correspondre à des scénarios d’utilisation.
  • Les tests de performances poussent le code dans ses retranchements (mémoire, rapidité, scalabilité, charge).

Les limites

La rédaction de tests est un fabuleux outils de design, un filet de sécurité et une documentation. Mais pour que ça marche, il faut prendre soin du code de test autant que du code de production. Il doit rester le plus clair possible, à jour et doit évoluer en même temps que le code de production.

Il faut parfois se méfier de l’envie de tester systématiquement chaque méthode, il vaut mieux tester des fonctionnalités. Il faut également garder une cohérence dans le code, le test est là pour mettre en avant les problèmes potentiels, il ne doit pas en créer. Les tests doivent être facilement utilisables et relativement rapides pour tous les développeurs au risque d’être délaissés et donc inutiles.

Références

IDE rails la suite : NetBeans puis RubyMine

Bien le bonjour, suite aux mésaventures avec Aptana (cf: Aptana, finalement pas…), j’ai tenté NetBeans puis Rubymine.

NetBeans

Installation

Une fois NetBeans installé, il faut télécharger  les plugins pour rails et les installer via Tools>plugins>downloaded. Et là, c’est le drame :

  • L’ordre d’installation des plugins du package n’est pas géré. Du coup, il faut le faire à la main.
  • Il me manque des plugins mais pas de lien direct pour les charger
  • Il n’y a pas de quoi sélectionner/déselectionner tout dans la liste des éléments téléchargés
  • L’installation met beaucoup, beaucoup de temps

Conclusion

Je n’ai peut-être pas eu de chance, et j’avais surement moins de patience qu’avec Aptana mais ça ne c’est pas bien passé. Au final, je n’ai pas résisté à la lenteur d’installation et aux problèmes de compatibilité et de gestion de dépendances de plugins, SUIVANT 🙂

RubyMine

Installation

Nouvelle IDE, nouvelle installation. Soyons clair, il s’agit d’un produit spécifique de développement rails payant (voir tarifs).  Mais cela veut dire aussi :

J’ai ajouté mon compte Github et j’ai précisé le projet que je voulais récupérer, aucun soucis pour la mise en place du projet. Puis, j’ai mis mon GemFile à jour pour lancer les tests avec test-unit et avoir quelques statistiques :
group :test, :development do
  gem 'sqlite3'
  gem 'test-unit'
  # Used by rubymine to display test statistics
  gem 'ruby-prof'
end

Les messages d’aide  sont clairs. Il y a même  une popup qui propose un lien pour lancer l’installation d’une Gem manquante.

Conclusion

C’est le seul qui ne m’a pas nécessité une recherche avancée pour installer mon environnement. Et c’est également le seul qui a pu me lancer mes tests sans problème. Je vous l’accorde, ce n’est qu’un début.  Je vais profiter du mois de période d’essai pour voir s’il vaut le coût. @bientôt

Reprise de Pibou : Git, Rails et Heroku avec Windows

Bien le bonjour,

Comme promis, nous allons continuer Pibou sous Windows. Au menu du jour :

  1. Installer un environnement de développement Rails sous Windows
  2. Récupérer le projet Pibou qui est resté au chaud sur github 
  3. Tester le déploiement du projet sur heroku depuis Windows

Ruby & rails

  • Pour installer Ruby sur notre poste, nous allons utiliser rubyinstaller & ruby developement kit (outils pour les extensions natives) téléchargeables tous deux sur http://rubyinstaller.org/downloads/
  • Une fois Ruby installé, nous trouvons tout ce qu’il nous faut dans C:\Ruby193\bin (par défaut) et RubyGem prêt à servir
  • Pour le kit de développement, il suffit de suivre les instructions du wiki
  • Vous risquez devoir installer Python, allez faire un tour sur http://www.python.org/getit/ (ajoutez le répertoire d’installation dans votre path)
  • Pour se préparer à l’utilisation de SQLite3, nous allons l’installer à partir du zip pour windows
    1. déposer avec délicatesse les fichiers sqlite3.dll & sqlite3.def dans notre répertoire tout neuf C:\Ruby193\bin
    2. Lancer la commande gem install sqlite3 dans votre shell préféré
  • Tant que nous avons le shell sous la main, installons rails avec la commande gem install rails (il y en a pour un petit moment)

Et voila, vous pouvez vérifier votre installation via les commandes ruby –version  & rails –version

IDE & Récupération du projet pibou

  • Si vous ne l’avez pas déjà, installez GIT
  • Nous allons installer Aptana histoire de tester l’un des IDE gratuit les plus utilisé pour le développement web.
  • Puis, nous allons utiliser l’import Git avec l’url github du projet https://github.com/jbdoumenjou/pibou.git
  • Nous allons profiter de problèmes de compatibilité pour mettre à jour le Gemfile
      • Petite mise à jour de Rails en 3.2.8
    gem 'rails', '3.2.8'
      • Nous allons passer therubyracer dans le scope de production
    group :production do
      gem 'pg'
      gem 'libv8', '3.11.8.0'
      # See https://github.com/sstephenson/execjs#readme for more supported runtimes
      gem 'therubyracer', :platform => :ruby
    end
  • Un bundle install plus tard et nous sommes à jour
  • N’oublions pas d’indexer nos changements
    • git add Gemfile Gemfile.lock
  • Puis de les ajouter au dépôt local
    • git commit -m « Worked on the configuration to develop under windows »
  • Ces modifications sont visibles sur github
  • Pour lancer le projet sur notre poste, il faut commencer par générer la base
    • rake db:migrate
  • Puis lancer le server
    • rails s
  • Et vérifier sur http://localhost:3000/movies que nous avons bien l’application

Le dépoilement sur Heroku

  • Installons heroku belt sous windows
  • Ensuite, il faut nous connecter au service heroku via une commande lancée à la racine du projet
    • heroku login
  • Ajoutons la clé ssh de notre nouvelle machine
    • heroku keys:add
  • Ajoutons le dépot heroku à nos dépots distants
    • git remote add heroku git@heroku.com:pibou.git
  • Et envoyons nos modifications sur le dépôt distant heroku (ça prend un moment):
    • git push heroku master

Finalement ca marche

Nous y sommes! Ruby et tous ses amis se sont invités sur notre Windows sans trop de soucis. Git ne semble pas récalcitrant et Aptana s’est montré docile, que demander de plus ?
Nous allons pouvoir reprendre le développement de Pibou sous Windows et découvrir Aptana

@bientôt

site officiel d'Heroku

Pibou dans les nuages avec Heroku

site officiel d'HerokuDans l’article précédent, Pibou – Partage ton code, nous avons ajouté les sources du projet sur Github via Git. Nous allons maintenant déployer le projet sur Heroku.

A quoi ça sert Heroku ?

Heroku est un service en ligne qui permet de déployer des applications dans « le cloud ». Concrètement ça permet :

  • De ne pas se soucier de l’infrastructure serveur
  • D’adapter les ressources en fonction de ses besoins (puissance/budget)
  • De profiter de git pour envoyer ses sources dans les nuages

Comment ça marche ?

Heroku utilise Git pour déployer l’application. Il s’agit en fait d’un nouveau dépôt de sources. Quand on pousse ses sources vers Heroku, il s’occupe de tout. Il faut quand même faire un peu de configuration. Pour aller plus loin -> http://www.heroku.com/how.

Mise en route

La documentation est bien faite, nous allons en profiter -> https://devcenter.heroku.com/articles/rails3.

Installation

Installer les outils ->  https://toolbelt.herokuapp.com/

Avoir un compte Heroku

  • Pour utiliser le service, il faut un compte. 😉 Ça se passe par ici -> https://api.heroku.com/signup Une fois l’enregistrement terminé, nous pouvons nous connecter via une commande lancée dans le Shell à la racine du projet : $heroku login
  • Lors de votre connexion au service, si on ne vous propose pas l’ajout de votre clé publique, vous pouvez le faire via la commande : $heroku keys:add
    Pour plus de détails -> https://devcenter.heroku.com/articles/keys

Configurer la base de données

Par défaut, nous avons des bases sqlite pour les tests, le développement et la production. Heroku demande une base en PostgreSQL. Nous allons donc :

  • Installer PostgreSQL sur son poste. Si vous rencontrez cette erreur https://gist.github.com/2400759, il suffit d’installer  la lib libpq-dev.
  • Mettre à jour le Gemfile pour prendre en compte la dépendance vers la gem ‘pg’ en environnement de production. Concrètement,  on modifie le fichier /pibou/Gemfile avec ces lignes :
group :test, :development do
  gem 'sqlite3'
end

# for heroku environment
group :production do
  gem 'pg'
end

  • Mettre à jour ces dépendances via la commande lancée à la racine du projet : $bundle install

Synchronisation des sources avec le dépôt Heroku

Le déploiement d’un projet sur Heroku se fait via l’envoie des sources sur un dépôt Git. Nous allons donc rajouter les fichiers que nous avons modifiés puis les envoyer sur nos dépôts :

Ajout des sources en local
$git add Gemfile Gemfile.lock config/database.yml
$git commit -m « Updated the dependencies »

Envoie des sources sur notre dépôt GitHub
$git push origin master

Déploiement Heroku
$git push heroku master

Mise à jour de la base de donnée distante

Tout se résume en une simple commande lancée à la racine du projet:
$heroku run rake db:migrate

Où est l’application ?

Si vous regardez votre Shell attentivement, vous verrez l’url de déploiement, pour moi -> http://pibou.herokuapp.com

En bref

Ce que nous avons réalisé :

Et après ?

Maintenant que nous avons une application déployée et un code partagé, nous allons pouvoir développer notre application de gestion de films. Mais pour bien faire, nous avons besoin de mettre en place des tests, ce sera le sujet suivant.

@bientôt

 

Pibou – Partage ton code

Dans l’article précédent, Pibou – scaffolding & structure, nous avons ajouté la notion de film et nous avons utilisé la génération de code. Il est grand temps de mettre en place un gestionnaire de versions.

Gestion des sources

Lors de la vie d’un projet, les sources évoluent sans cesse. Il est donc très important de pouvoir stocker les changements et rendre les sources accessibles à tous les acteurs du projet. Dans cette optique, nous allons utiliser GIT.

Utilisation de GitHub

Afin d’éviter les contraintes de l’installation de la partie serveur, nous allons utiliser un service en ligne : GitHub. C’est un outil bien pratique qui fourni entre autres :

  • Un dépôt de source en ligne
  • Un suivi des sources
  • Un wiki
  • Des statistiques
  • Suivi de bugs
  • Un outil de partage de code indépendant (gist)

Il existe plusieurs formules d’abonnements, celle de base est gratuite et vous permet 300Mo de stockage publique. Si vous voulez héberger des projets privé, il vous faudra dépenser au moins 7$/mois. Pour plus d’informations tarifaires : https://github.com/settings/billing.

Créer un projet GitHub

La documentation sur GitHub étant très complète, je vous laisse découvrir la création du projet et l’installation de Git (attendez un peu avant d’envoyer le code) :

Définir des règles d’exclusion de fichiers pour git

Nous allons rajouter un fichier pibou/.gitignore afin de définir les fichiers et/ou dossier qui n’ont rien à faire sur le dépôt. Vous pouvez trouver des exemples ici : https://github.com/github/gitignore. Nous allons compléter le fichier existant avec : https://github.com/github/gitignore/blob/master/Rails.gitignore.

Le premier push

  • Tout d’abord, nous nous plaçons à la racine « /pibou »
  • Ajout des sources $git add -A (le -A permet un ajout de toutes les sources. On l’utilise pour cette fois, mais nous ciblerons dorénavant les fichiers à ajouter)
  • Si vous n’avez pas encore désigné votre dépôt distant : $git remote add origin git@github.com:<username>/pibou.git
  • Le code est seulement enregistré en local, pour l’envoyer sur le serveur : $git push -u origin master

Pour plus de détails sur le partage d’un projet : http://help.github.com/create-a-repo/

Le petit plus de RVM

N’oublions pas notre configuration ruby! RVM permet de créer un fichier .rvmrc qui fourni une configuration par projet. Pour cela, une petite commande à la racine du projet : $rvm ruby-1.9.3-p125@pibou –create –rvmrc (lire : interpréteur ruby-version@gemset)

Maintenant que nous avons une configuration de l’environnement ruby pour le projet, il suffit de le partager :

git add .rvmrc
git commit -m "Added ruby environment configuration"
git push origin master

Et voilà, votre code est sur le dépôt et vous avez partagé votre configuration rvm via votre .rvmrc. Pour plus de détails : http://beginrescueend.com/workflow/rvmrc/

Et après?

Je vous laisse digérer tout çà. La prochaine fois, nous allons déployer notre application en ligne grâce à heroku. En attendant, vous pouvez accéder aux sources du projet sur https://github.com/jbdoumenjou/pibou

@bientôt

Pibou – scaffolding & structure

La dernière fois, nous avons créé le projet et lancé l’application (Pibou, rails & premier déploiement). Il est temps de réaliser notre première page et de comprendre un peu mieux les rouages du projet.

La magie du scaffolding

Le scaffolding est tout simplement un outil de génération de code dont nous allons nous servir pour créer nos premiers fichiers. La structure sera la plus simple possible: un film possède un titre. Avant de commencer, il faut savoir que Rails utilise un pattern MVC pour la structure du projet.

$rails generate scaffold Movie title:string

On peut revenir en arrière via la commande :

$rails destroy scaffold Movie

Mais intéressons nous plutôt aux fichiers créés ou modifiés lors du generate.

Les données

La génération commence par la création d’un fichier de migration dans « pibou/db/migrate ». Le nom du fichier généré utilise un timestamp et le nom de l’action (create movies). Ce fichier de migration est utilisé pour la mise à jour de la base de données.

Nous allons appliquer la migration via la commande lancée à la racine du projet :

$rake db:migrate

Cette commande permet d’appliquer les migrations au schéma de la base dans « pibou/db/schema.rb ». Pour de plus amples informations sur ces mécanismes : http://guides.rubyonrails.org/migrations.html.

Le model

Dans « pibou/app/models/ », on retrouve notre modèle, dont notre objet  fraîchement créé « movie.rb ».

class Movie < ActiveRecord::Base
end

Le contenu de ce fichier peut être déroutant, en fait il est pratiquement vide. Il faut s’habituer à avoir tous les attributs présents dans le schéma de la base : « pibou/db/schema.rb ».

ActiveRecord::Schema.define(:version => 20120311175909) do

  create_table "movies", :force => true do |t|
	t.string   "title"
	t.datetime "created_at", :null => false
	t.datetime "updated_at", :null => false
  end

end

Les tests

Les tests unitaires se situent dans « pibou/test/unit/ », ils utilisent par défaut des fichiers yaml présent dans « pibou/test/fixtures/ ». Il existe également des tests pour les contrôleurs dans « pibou/test/functionnal/ ». Pour aller plus loin : http://guides.rubyonrails.org/testing.html.

Les contrôleurs

Ils sont présents dans « pibou/app/controllers ». Pour l’instant nous avons 2 contrôleurs :

  • application_controller.rb qui est le contrôleur dont hérite tous les autres contrôleurs.
  • movies_contoller.rb qui fourni le comportement et le rendu associé

Le scaffolding a généré toutes les méthodes de bases. Pour plus de détails : http://guides.rubyonrails.org/action_controller_overview.html.

Les vues

Elles se trouvent dans « pibou/app/views/ ». Pour chaque objet du model, on va retrouver un répertoire qui contient le rendu des différentes actions :

  • « pibou/app/views/movies/index.html.erb » => liste des films
  • « pibou/app/views/movies/edit.html.erb » => edition d’un film
  • « pibou/app/views/movies/show.html.erb » => visualisation d’un film
  • « pibou/app/views/movies/new.html.erb » => création d’un film
  • « pibou/app/views/movies/_form.html.erb » => le _ indique un partial, pour faire simple un template de formulaire réutilisable.
Pour plus de détails sur le rendu : http://guides.rubyonrails.org/layouts_and_rendering.html.

Les helpers

Ils trouvent dans « pibou/app/helpers » et sont, comme leur nom l’indique, des classes fournissant des méthodes d’aide réutilisables dans les vues (formatages etc…). Dans notre cas, « pibou/app/helpers/movies_helper.rb ». Les tests des helpers sont dans « pibou/tests/helpers ».

Les assets

Trois fichiers sont générés :

  • « pibou/app/assets/stylesheets/movies.css.scss » pour la feuille de style (sass) spécifique aux films
  • « pibou/app/assets/stylesheets/scaffolds.css.scss » pour la feuille de style (sass) générale
  • « pibou/app/assets/javascripts/movies.js.coffee » pour le javascript (coffescript)

Les extensions

Vous avez pu remarquer les extensions « doubles » sur les fichiers telles que .css.scss ou .html.erb, il s’agit d’une convention bien pratique. Prenons le cas .html.erb => il faut lire fichier en erb qui génère du html.

Les routes

Il s’agit du fichier « pibou/config/routes.rb ». Ce fichier est très important et vous aurez à le manipuler avec soin. Il permet de définir la gestion des url : qui répond à quoi. Dans notre cas, la génération a ajouté

resources :movies

Cette ligne spécifie que toutes les opérations de bases sont routées. Pour en avoir le coeur net, une petite commande que vous utiliserez souvent (à la racine du projet):

$rake routes

Vous avez maintenant la liste des url et actions http associées avec un contrôleur. Par exemple :

movies     GET     /movies(.:format)    movies#index

Lire qu’un get sur movies quelque soit le format est redirigé sur la méthode index du contrôleur de movies. Pour simplifier, http://127.0.0.1:3000/movies est traité par la méthode index de movies_controller. Pour plus d’informations : http://guides.rubyonrails.org/routing.html.

L’application

Bon, c’est bien joli tout ça, mais au final on a quoi ? Je vous propose de lancer votre serveur et d’aller voir l’application :

$rails server

Dans votre navigateur favori : http://127.0.0.1:3000/movies.

Bienvenue dans votre application, vous pouvez ajouter des films, les voir et les supprimer. Vos données sont sauvegardées dans « pibou/db/development.sqlite3 ». Nous approfondirons dans un prochain article.

Et après ?

Maintenant que nous avons quelque chose à partager, le prochain article abordera l’utilisation de Git et GitHub.

@bientôt

 

Pibou, rails & premier déploiement

La dernière fois, nous avons installé RVM et ruby. Il est grand temps d’installer rails et de créer notre projet.

Installation de rails

Pour l’installation de nouveau packages c’est RubyGems qui s’en charge. Une petite ligne de commande : $gem install rails

Si vous avez eu une erreur lors de cette commande du style :

ERROR: Loading command: install (LoadError)
no such file to load — zlib
ERROR: While executing gem … (NameError)
uninitialized constant Gem::Commands::InstallCommand

Il faut supprimer la version de ruby, installer le package zlib et réinstaller votre version via rvm :
$rvm remove 1.9.3-p125
$rvm pkg install zlib
$rvm install 1.9.3-p125
$gem install rails

Création du projet « Pibou »

Une ligne de commande :
$rails new pibou

Et voila votre nouveau projet, mais que s’est-il passé ?

  1. Création de toute l’arborescence du projet
  2. Utilisation de Bundler pour récupérer toutes les gems définies dans le Gemfile

Pour l’arborescence, nous allons la découvrir plus en détails au prochain article.

En ce qui concerne Bundler, c’est un gestionnaire de dépendances qui utilise un fichier de configuration que vous pouvez voir dans « /pibou/Gemfile ». C’est un mécanisme similaire à celui de maven avec ses fichiers pom.xml, l’analogie s’arrêtera là.

Il faut d’ailleurs éditer le fichier « /pibou/Gemfile » pour s’éviter une erreur de configuration de runtime JavaScript. Une ligne est prévue à cet effet :

# See https://github.com/sstephenson/execjs
# readme for more supported runtimes
# gem 'therubyracer'

Il suffit de dé-commenter la ligne 18. Puis d’appliquer ces changements via une commande lancée depuis la racine du projet :

$bundle install

Déploiement

Une ligne de commande :
$rails server

Un serveur WEBrick est lancé sur le port 3000 et vous pouvez accéder à votre application en local (127.0.0.1:3000) via votre navigateur préféré. La page que l’on peut voir est en fait une page html statique qui est disponible dans le répertoire « /pibou/public/index.html »

Et ensuite ?

Nous avons installé rails et créé le projet. Dans le prochain épisode :

  • Génération du code
  • Tour d’horizon du projet

@bientôt

Pibou, philosophie & ruby

Voilà la suite de notre fil rouge! Aujourd’hui nous allons installer le poste de développement. Je travaille sous MacOS, le comportement est similaire sous Linux (testé sous Ubuntu), je serais ravi d’avoir des retours d’utilisation sous windows.

Philosophie & Acronymes

  • KISS : « Keep it simple, Stupid » -> on reste simple, du code explicite et clair.
  • YAGNI : « You’re Ain’t Gonna Need It! » -> On ne fait pas si on en a pas besoin maintenant.
  • DRY : « Don’t Repeat Yourself » -> on prend garde aux répétitions inutiles, et on pense bien son code.
  • Convention Over Configuration -> on respecte des conventions de code pour limiter au maximum la configuration, rails est là pour vous simplifier la vie.
  • REST : « Representational State Transfert » -> architecture classique du web centrée autour des ressources plébiscitée pour sa simplicité.

Installation du poste de développement

Les outils

Pour installer vos outils sous MacOS, je vous conseille vivement HomeBrew. Je l’ai trouvé plus efficace que MacPort et permet un confort similaire à apt-get pour les linuxiens.

Lorsqu’on travaille avec ruby, on peut être facilement amené à gérer plusieurs versions qui sont malheureusement non compatibles. Il est donc judicieux d’utiliser des outils afin de ne pas se mélanger les pinceaux. En voici deux :

  • RVM (Ruby Version Manager) : celui que j’ai découvert en premier et que j’utilise encore. Très pratique, il permet de configurer des gemsets et de faire les installations des versions.
  • rbenv : se concentre uniquement sur la gestion des versions en étant non intrusif contrairement à RVM qui fourni plusieurs services.

Pour commencer, nous allons utiliser RVM qui nous permettra de cibler des installations et jouer avec la configuration.

Installation de RVM & Ruby

Nous allons installer la dernière version de ruby disponible puis configurer notre environnement via RVM (guide d’installation):

  1. Installer RVM -> $bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)
  2. Installer ruby 1.9.3 -> $rvm install 1.9.3-p125
  3. Sélectionner ruby 1.9.3 -> $rvm use 1.9.3-p125
  4. Vérifier sa version (ruby 1.9.3p125) -> $ruby –version
  5. Pour sélectionner cette version par défaut pour la configuration rvm -> $rvm use 1.9.3-p125 –default

Et voila vous avez ruby 1.9.3 installé et sélectionné.

 Et après ?

Nous avons abordé la philosophie du projet et l’utilisation de RVM. Dans le prochain épisode :

  • l’installation de rails
  • la génération du projet
  • notre premier déploiement

@ bientôt