Gregoire-penverne.Fr vient, récemment, de passer d'une version php à une version Ruby (en utilisant le framework Ruby On Rails). L'occasion, pour moi, de découvrir ce langage, et d'évaluer les avantages et inconvénients par rapport au Php, qui reste mon langage de référence (comprendre : celui que je connais le mieux). 1) Le Modèle MVC La structure Model-View-Controller n'est pas spécifique à Ruby, ni au framework ROR (Ruby On Rails). Je l'ai découvert avec le framework Zend, en php, et me suis aperçu que c'était, grosso-modo, ce que je faisais déjà en php, sans utiliser de framework spécifique. Mais alors que Zend Framework et son organisation MVC m'ont semblé très (trop?) contraignants, et m'ont fait d'avantage perdre de temps qu'ils ne m'en ont fait gagner, la structure MVC de Ruby on Rails m'a convaincu, totalement et sans réserve. En dehors du fait que cette organisation permet un gain de temps dans le développement, en séparant les interactions BDD et l'affichage des résultats, elle nous contraint, surtout, à suivre une certaine rigueur, très pratique pour les autres personnes susceptibles de travailler sur vos codes. On trouve donc rapidement quel fichier modifier. Mais ce n'est pas réellement là une force spécifique à Ruby on Rails. Disons que c'est une logique agréable à suivre dans ce Framework.   2) La structure BDD En php, je commence par créer ma base de données, en fixant les clefs, etc. Après quoi, je fais mon code en tenant compte de la structure que je viens de mettre en place (bien entendu, la structuration en base de données est réfléchie afin d'optimiser les futures requêtes mysql que l'on fera dessus). En ruby, on crée un model (en ligne de commande, via rails generate model lenomdumodel ), et rails créer un fichier de création de base de données. De type :

class CreateArticles < ActiveRecord::Migration def self.up create_table :articles do |t| t.integer :user_id t.string :title t.text :resume t.text :content t.integer :public t.timestamps end end   def self.down drop_table :articles end end  

On le voit, donc, tout est écrit dans un fichier dans lequel on spécifie les types de données. Cela facilite la migration du site en cas de besoin, en nous épargnant l'export de la structure des tables. t.timestamps indique que rails va automatiquement ajouter à la structre 2 champs : created_at, et update_at . Le champs update_at sera mis à jour automatiquement à chaque modification de l'enregistrement. Inutile de spécifier de champs id, rails l'ajoute automatiquement.   3) Les requêtes MySQL On ne les voit même pas, dans le code source. Il suffit en fait de faire appel à des "modèles", qui interrogent la base de données à notre place. Par exemple, en reprenant le modèle décrit ci-dessus, on va pouvoir récupèrer un article portant l'id "3" de cette façon : article = Article.find(3)   De la même façon, si l'on souhaite récupèrer les articles d'un utilisateur (pour l'exemple, d'id 7), nous allons pouvoir procéder de 2 façons : - articles = Article.where(:user_id=>7) ou.... - articles=User.find(7).Articles   Et le mieux, c'est la création d'un nouvel enregistrement en base de données. Par exemple : article = Article.new(:author=>author_id, :titre=>"mon_titre") article.save   Et pour supprimer l'enregistrement : article.delete   4) Les collections Et là, c'est l'une des immenses forces de ruby on rails (tout du moins, il s'agit d'une fonctionnalité qui m'a tout particulièrement plu). Par exemple, imaginons que, comme présenté ci-dessus, nous disposions d'un article d'id 3 On a donc, dans notre code : article = Article.find(3)   Pour récupèrer les commentaires de cet article : comments = article.Comments Donc, pas de requêtes à proprement parler: et c'est très joli à lire. :)   5) Le cache Je n'ai pas vraiment pris le temps de me pencher d'avantage dessus. Néanmoins, j'ai pu constater que RubyOnRails propose de mettre en cache les controllers, et les models, afin d'économiser de la charge serveur. Bien entendu, ce cache ne doit être activé qu'en production (à moins de ne souhaiter de devoir redémarrer apache à chaque modification en préprod, ce qui serait... illogique... )   6) La gestion des erreurs Les erreurs trouvées par Ruby sont placées dans un fichier production.log (ou development.log, ou test.log), et sont, je trouve, bien détaillées : Un exemple d'erreur : ActionView::Template::Error (compile error /var/www/gpenverne/full/app/views/un_controller/index.rhtml:1: syntax error, unexpected kDO ...Buffer.new; @comments.each |do| comment ^ /chemin/full/app/views/un_controller/index.rhtml:15: syntax error, unexpected kENSURE, expecting $end): 1: <% @comments.each |do| comment %> 2: Sur l'article : 3:

<%= comment.article.title %>

  4: <%= raw comment.content %> app/views/un_controller/index.rhtml:15:in `compile'   Le log nous donne le fichier contenant l'erreur, et le message d'erreur (rien d'exceptionnel jusque là, apache en fait de même pour php...). Mais ce qui est pratique, c'est que le fichier log contient également un extrait du contexte de l'erreur. On voit rapidement si l'erreur vient du controller, ou de la vue.   7) La syntaxe Même si j'en ai pris l'habitdue, je me dis, qu'au final, le ";" en fin d'instruction en php est un peu stupide, fondamentalement. Ruby, donc, s'en passe, et affiche une instruction par ligne. (bien entendu, c'est un intérêt relativement limité, mais tout de même). De la même façon, les structures conditionnelles sont plus "jolies" à lire :  

if params[:title] && params[:resume] && params[:content] @article = Article.new(:title=>params[:title], :user_id=>@current_user.id) @article.save end

  Pas d'accolades ( { - } ), et un "end" pour terminer la structure. Toutes les informations GET/POST sont accessibles via le tableau params. Même si vous ne connaissez pas ruby, je pense que vous pouvez déjà comprendre à quoi sert cette portion de code: la lecture du code est simple, et se fait sans trop de difficultés.   8) Le temps d'exécution Grâce à la gestion des requêtes par Ruby on Rails, j'ai trouvé le site gregoire-penverne.fr (version ruby) plus rapide que dans sa version PHP. Je suppose qu'il s'agit de l'optimisation des requêtes, mais peut être que cela soulève également la question de la rapidié d'exécution du code Ruby par rapport à l'exécution du code PHP   9) Sécurité En php, j'ai pris l'habitude de mettre des systèmes de token afin d'éviter les failles CSRF (sur les bons conseils de @boiteaweb). Ruby on Rails (vous me direz ; zend aussi ...) permet de les intégrer directement aux formulaires :

<% form_tag "/user/subscribe" do %> <% end %>

Par exemple, le code ci-dessus génère les balises forms qui vont bien, avec le token anti-CSRF en champs hidden.   10) Le code dans les vues L'on peut mettre du code ruby directement dans les vues ou le layout (comme on l'eut fait avec une classe smarty en php, ou avec Zend), par exemple  

Bienvenue <%= @current_user.name %>

    Mais grâce à ruby, on peut également automatiquement inclure dans notre layout les javas contenus dans un répertoire, en une ligne :

<%= java_include_tag ":all" %>

      J'imagine qu'il existe bien d'autres raisons pour lesquelles Ruby On rails vaut qu'on s'y intéresse (et peut être même de meilleurs raisons). A mon stade de la découverte de ce langage, ces 10 points sont ceux qui m'ont le plus plu, et qui font que je pense développer plus souvent en Ruby, tant pour apprendre d'avantage, que pour le plaisir de gagner du temps, tout en faisant du zoli code.     Et vous, avez-vous essayé ?