Pourquoi Ruby et Ruby On Rails dans le développement d'application web ?

Cette question a été posée dernièrement sur la Mailling List de RailsFrance. Effectivement, si on veut promouvoir Ruby dans le monde informatique français, il faut pouvoir argumenter pourquoi on trouve que c'est une bonne idée.

Tout le monde est en droit de se poser la question. Voici donc, pour moi, l'avantage de Ruby par rapport aux autres technologies à l'heure actuelle.

Ruby c'est fun

Matz, quand il a créé Ruby, a voulu faire un langage fun avec lequel il pourrait s'amuser à coder. Aujourd'hui tous les développeurs Ruby diront à peu près la même chose. Coder en Ruby est plaisant. L'avantage de ce point est qu'un développeur Ruby est plus détendu. Un développeur détendu est un développeur plus heureux. Un développeur plus heureux est motivant pour une équipe. Un développeur heureux essayera de faire son travail proprement. L'ambiance d'une équipe de développeur Ruby peut ainsi être agréable. Moins de stress sur un projet, c'est un projet qui part avec un peu plus de chances de réussir.

Ruby aime les tests

La communauté Ruby actuelle est convaincue de l'utilité des tests unitaires. Ainsi, chaque librairie est poussée par la communauté à avoir des tests. Beaucoup de développeurs, moi y compris, privilégierons une librairie avec des tests unitaires plutôt qu'une sans aucun tests.

Cette philosophie permet d'avoir un environnement de développement de test simplifié directement dans Rails. Pas besoin de se prendre la tête pour faire des tests. Si vous ne faites pas de tests de base : soit vous ne voulez pas en faire, ce que je ne recommande pas, soit vous le faites exprès.

Ruby aime le cloud

En ce moment, l'évolution logique du net est le Cloud Computing. L'idée du Cloud Computing est simple. Nos sites internet ne sont plus hébergés sur une seule machine. Les services sont séparés pour améliorer la scallabilité. Au sein de la communauté Ruby, les développeurs sont très attachés à cette idée. Ainsi beaucoup d'utilitaires pour gérer et utiliser son cloud commencent à voir le jour comme Chef. L'architecture même de Rails permet de facilement sortir de Ruby On Rails pour ainsi utiliser son Cloud. ActiveRessource en est la preuve.

Mais coder dans un Cloud implique de coder plusieurs briques. Le Ruby a des bindings pour tous ces utilitaires, comme les systèmes de queues ou les bases de Données Non-Relationnelle. Je ne dis pas que les autres ne peuvent pas le faire. Mais là encore c'est un effet de groupe. Chaque développeur ruby a envie de jouer avec un Cloud. On pense de plus en plus en cloud.

Les plugins de Rails

Ruby On Rails possède une très grande quantité de plugins. On peut ainsi facilement trouver la petite brique que l'on cherche pour sa propre utilisation. C'est plus que l'utilisation d'un module Drupal. Car là nous sommes dans un environement facilement modifiable et sans aucune limitation. Chose que Drupal peut vite avoir.

Les Ressources

Le plus grand reproche que l'on fait actuellement au choix de Ruby On Rails, c'est le manque de ressources. Effectivement, les ressources de développeurs Ruby sont plus faibles que pour d'autres langages. Mais ceci est selon moi un faux problème. L'apprentissage de Ruby et Ruby On Rails est assez simple si on connait la logique Objet. Ainsi, n'importe quel développeur Java peut tout à fait se mettre à Ruby et Ruby On Rails. Donc avec un expert Ruby/Rails, on peut former facilement une équipe complète et compétente.

Cet argumentaire n'engage bien sûr que moi et peut donc être sujet à caution.

Sortie de Typo 5.4.0

Ça y est, une nouvelle version de Typo est lancée dans la nature. Je n'ai hélas que très peu participé à cette nouvelle version faute de motivation/temps. Mais je suis toujours très content de voir une nouvelle version de ce blog sortir.

A chaque release, une nouvelle admin fait son apparition, mais à chaque fois elle est meilleure que la précédente, donc c'est une excellente chose.

J'ai bien-sûr mis à jour ce blog et j'ai aussi switché sur le nouveau thème par défaut. Je suis toujours aussi nul en design.

En petit cadeau, voici mon fichier capistrano que j'utilise pour déployer ce blog. Ça peux toujours vous servir. On ne sait jamais.

set :application, "typo"
set :repository,  "git://github.com/fdv/typo.git"
set :domain, "blog.shingara.fr"

# If you aren't deploying to /u/apps/#{application} on the target
# # servers (which is the default), you can specify the actual location
# # via the :deploy_to variable:
set :deploy_to, "/var/rails/blog-typo"
#
# # If you aren't using Subversion to manage your source code, specify
# # your SCM below:
set :scm, :git

set :runner, "rails"
set :user, "rails"
set :use_sudo, false

set :thin_conf, "/etc/thin/#{domain}.yml"

role :app, domain
role :web, domain
role :db,  domain, :primary => true

task :update_config, :roles => [:app] do
  run "cp -Rf #{shared_path}/config/* #{release_path}/config/"
  run "ln -s #{shared_path}/files #{release_path}/public/files"
end

task :update_gems, :roles => [:app] do
  run "cd #{release_path} && RAILS_ENV=production rake gems:install"
end


after "deploy:update_code", :update_config
after "deploy:update_code", :update_gems


namespace :deploy do
  task :start, :roles => [:app] do
    run "thin -C #{thin_conf} start"
  end

  task :stop, :roles => [:app] do
    run "thin -C #{thin_conf} stop"
  end

  task :restart, :roles => [:app] do
    run "thin -C #{thin_conf} restart"
  end
end

task :clear_cache, :roles => [:app] do
  run "cd #{current_path} && RAILS_ENV=production rake sweep_cache"
  run "cd #{current_path} && RAILS_ENV=production rake tmp:cache:clear"
end

after "deploy:restart", :clear_cache
after "deploy:start", :clear_cache

English Translation

Sortie de Oupsnow 0.4.0

Ca y est, Oupsnow 0.4.0 est enfin sorti. Cette version est un refactoring quasiment complet. Après avoir eu une version 0.3.0 en Merb/DataMapper, cette version est désormais en Rails/MongoDB. Le back-end et le serveur ont changé.

Cette nouvelle version, outre son refactoring comprend aussi l'ajout de quelques nouvelles fonctionnalités.

• Ajout d'un filtre par Status dans la recherche de ticket
• Ajout de la possibilité de changer la fonction de tous les membres d'un project
• Ajout de la preview des tickets et commentaires sur les tickets
• Ajout de la visualisation de la milestone courante dans la visualisation d'un ticket
• Possibilité d'ordonner tous les champs de recherche dans la vue des tickets
• Login par l'email et plus par le pseudo

Vous pouvez télécharger cette version sur rubyforge

Si vous souhaitez tester cette version, une version de demo de oupsnow est en ligne. Les login/mdp sont : admin@admin.com/oupsnow. Amusez vous bien.

Comment tester devise ? réélement ?

Alors que j'ai cherché comment tester facilement Devise. J'ai indiqué une technique dans mon précédent post. Mais cette technique est loin d'être la meilleure. Voici donc la nouvelle solution, la solution officielle.

Il suffit d'inclure Devise::TestHelpers. Ensuite pour se logger avec un utilisateur, on utilise la méthode sign_in. La méthode sign_out existe aussi.

Devise ? c'est bien, mais il faut le tester.

Alors que j'ai évoqué ma migration de Merb à Rails pour Oupsnow, il a fallu trouver un système d'authentification ORM Agnostique.

Le plugin d'authentification le plus connu à l'heure actuel est Authlogic. Ce plugin est vraiment très performant, mais tous les essais de le rendre ORM Agnostique ont été vain. C'est alors qu'au même moment, durant le Rails Summit 2009, George Guimarães et Carlos Antonio annoncent la sortie de Devise, un plugin Rails au dessus de Warden ( Rack middleware d'authentification). C'est exactement, ce qu'il me faut, un nouveau système d'authentification a tester et peut-être une possibilité d'ajouter une couche d'ORM Agnostique dedans. En plus Warden étant un RackMiddleware, je pourrais un peu tester ce que ça donne.

J'installe donc Devise et commence à l'utiliser dans Oupsnow. Tout se passe à merveille, jusqu'au moment où il faut faire les tests. Tout de suite le bât blesse. Les tests controlleurs de Rails ne communiquent pas avec la couche Rack qui n'est pas initialisée. On se retrouve donc avec une impossibilité de définir si un utilisateur est loggé ou non et si oui, qui est cet utilisateur.

Après de nombreux tests et essais. J'ai fini par trouver comment faire. Warden ajoute à la requête une variable d'environment dans la requête. On peux y accéder par request.env['warden']. Il suffit donc de remplir cette variable.

Pour avoir un utilisateur non loggé, il faut faire :

def unlogged
  request.env['warden'] = Warden::Proxy.new(request.env, {:default_strategies => [:rememberable, :authenticable],:silence_missing_strategies => true})
end

Pour se logger avec un utilisateur en particulier il faut faire :

def logged_as(user)
  proxy = Warden::Proxy.new(request.env, {:default_strategies => [:rememberable, :authenticable], :silence_missing_strategies => true})
  proxy.set_user(user, :store => true, :scope => :user)
  request.env['warden'] = proxy
end

Personnellement, j'aime beaucoup devise. A tel point que j'ai permis de le rendre ORM Agnostique et compatible avec MongoMapper.

EDIT du 30 Novembre 2009: la technique indiquée ici n'est pas optimum et ne marche pas avec les dernières versions de Devise. utilisez plutôt la technique décrite dans mon ticket Comment tester devise ? réélement ?

Observer Vs Callback

Il y a peu au boulot, j'ai indiqué ma désapprobation des Observeurs face au Callback. Je vais donc le coucher ici par écrit mon sentiment.

L'Observeur

Dans Rails, il y a au premier abord une fonctionnalité vraiment intéressante. L'Observeur. Grâce à lui, on peux définir une classe qui vérifie le comportement d'un model et effectue certaine action suite à ses observations. Il permet d'ajouter des événements avant/après l'enregistrement, la mise a jour ou la destruction d'un model.

Pour mettre en place un observeur, il suffit de créer une classe héritant de ActiveRecord::Observer, mettre son code dedans et la définir comme observeur dans le fichier environment.rb. Rien de plus simple et ça marche très bien.

Le Callback

Mais Rails a déjà intégré dans ses models, les fonctions de callback utilisé par le observeur. En effet, on peux tout à fait définir N action after_save ou before_create. Ces méthodes seront appelés à l'événement voulu.

Mais que choisir ?

C'est là où je dis que le callback est plus intéressant que l'observeur. En effet, un callback fait exactement la même chose qu'un Observeur. Mais lui au moins on sait qu'il est là. En ouvrant la classe on découvre le callback. Pour détecter un Observeur, il faut regarder les fichiers de config de Rails et ouvrir une à une les classes Observeurs.

Même le cas du nombre de ligne n'est pas réel car il est tout à fait possible de sortir ses callbacks dans des modules. De même pour une réutilisation sur plusieurs classes. Le module le permet sans problème.

Personnellement, je n'ai jamais constater un seul cas où l'observeur avait plus d'intérêt que des callback. Si vous en trouvez, je suis vraiment curieux.

sortie de typo 5.2

A mon tour de vous annoncer la sortie de Typo 5.2. Cette sortie est la première sortie où je participe activement. En effet, depuis Août dernier, je suis contibuteur de Typo. J'ai d'abord commencé par faire la migration de Typo sur Rails 2.2 (avant même la sortie officiel de Rails 2.2). J'ai ensuite continué avec Frédéric à améliorer au maximum les performances et l'utilisabilité de Typo.

Aujourd'hui avec cette sortie de Typo, le travail est vraiment à la hauteur. Nous avons tout fait pour que cela soit optimum. Mais surtout nous n'avons pas fini. Nous avons ainsi énormément d'idée qui seront intégré dans Typo dans le futur. Nous allons aussi essayé de faire des releases plus régulièrement.

En bonus, voici mon fichier capistrano que j'utilise pour déployer Typo.

set :application, "typo"
set :repository,  "git://github.com/fdv/typo"
set :domain, "shingara.fr"

# If you aren't deploying to /u/apps/#{application} on the target
# servers (which is the default), you can specify the actual location
# via the :deploy_to variable:
set :deploy_to, "/var/rails/blog-typo"

# If you aren't using Subversion to manage your source code, specify
# your SCM below:
set :scm, :git
set :git_enable_submodules, 1

set :runner, "rails"
set :user, "rails"
set :use_sudo, false
set :thin_conf, "/etc/thin/typo.yml"

role :app, domain
role :web, domain
role :db,  domain, :primary => true

task :update_config, :roles => [:app] do
  run "ln -s #{shared_path}/config/database.yml #{release_path}/config/database.yml"
  run "ln -s #{shared_path}/files #{release_path}/public/files"
  run "ln -s #{shared_path}/cache #{release_path}/tmp/cache"
  run "ln -s #{shared_path}/newrelic_rpm #{release_path}/vendor/plugins/newrelic_rpm"
  run "ln -s #{shared_path}/config/newrelic.yml #{release_path}/config/newrelic.yml"
  run "ln -s #{shared_path}/config/agent #{release_path}/config/agent"
  run "ln -s #{shared_path}/config/mail.yml #{release_path}/config/mail.yml"
end

task :dump_before, :roles => [:app] do
  run "pg_dump -U typoblog typo > #{shared_path}/typo#{Time::today.strftime('%Y-%m-%d')}.sql"
end

namespace :deploy do
  task :start, :roles => [:app] do
    run "thin -C #{thin_conf} start"
  end

  task :stop, :roles => [:app] do
    run "thin -C #{thin_conf} stop"
  end

  task :restart, :roles => [:app] do
    run "thin -C #{thin_conf} restart"
  end
end

after "deploy:update_code", :update_config
before "deploy:migrations", :dump_before

English translation

Quelque nouvelles dans Rails Edge : Render(:file => '/path/to/file') devient render('/path/to/file')

Comme tout nos efforts sont désormais à consacrer à Rails. Voici la dernière nouveauté que je viens de trouver dans les commits. Hier le render a été simplifié. En effet, quand vous souhaitez faire un render de fichier il fallait faire : render (:file => '/path/to/file'). Désormais avec ce nouveau commit, un simple render('/path/to/file') suffira pour rendre le fichier donné.

Par contre attention, pour que ce path sont considéré valide, il faut absolument le / au début. Mais heureusement ce code render(Rails.root('/public/404.html')) fonctionnera, grâce à un précédent commit[...]

Le noël de la fusion entre Merb et Rails. Qu'en penser ?

Hier, 23 décembre la core Team de Merb et celle de Rails ont annoncé conjointement leur prévision de fusion pour Rails 3. En effet, Merb 2 sera Rails 3. Personnellement, j'ai été abasourdi par cette annonce. Immédiatement, je l'ai pris comme une mauvaise chose. J'ai tout de suite pensé que ce n'était pas forcément une bonne chose pour les Frameworks web en Ruby.

En effet, mon premier argument dans le fait de la dualité Rails/Merb était la concurrence. Je prenais comme exemple la guerre des navigateurs qui durant la période IE vs Netscape a apporté le Javascript. Puis une fois cette guerre fini, il y a eu la stagnation des navigateurs et de IE 6 qui avait son monopole. Heureusement, Firefox/Safari/Opera sont arrivé progressivement, pour permettre de bonne amélioration dans les navigateurs et de meilleurs performances. C'est ainsi que Internet Explorer a eu besoin de revenir au source et reprendre son développement qui va maintenant amener IE 8. Sans cette concurrence, nous aurions surement eu IE 6 encore maintenant (même si il reste encore beaucoup de monde qui l'utilise). De même, la « guerre » entre Mephisto et Typo est une bonne chose et nous force a rester dans la course. Éviter l'attentisme.

Selon moi, les dernières grandes améliorations de performances de Rails sont issue de cette « guerre » entre Merb et Rails, que ça soit Rails thread safe ou l'utilisation de Rack dans Rails. Mais Rails a aussi été obligé d'innover encore plus pour ne pas se faire doubler par Merb avec son Rails Metal par exemple ou l'incorporation de l'i18N

Désormais avec cette incorporation de Merb dans Rails, Rails va encore plus progresser durant l'année à venir, c'est évident. Pour cela, cette annonce est vraiment une bonne nouvelle. Mais ne va-t-elle pas entrainer aussi une stagnation après toutes ces améliorations et cette évolution de Rails. Rails n'ayant plus de concurrent « sérieux » en ruby ne va-t-il pas se reposer sur ses lauriers ?

C'est la que finalement, la communauté aura son rôle à jouer. C'est dans cette seconde partie de l'incorporation de Merb qui est tout se jouera pour l'avenir de Rails. L'idée de constituer une vrai équipe d'Evangéliste avec l'incorporation des Evangéliste de Merb comme Matt Aimonetti. Ainsi Matt explique dans son post au sujet de l'incorporation des idées de Merb dans Rails, qu'une des bonnes attitudes de Merb était cette écoute constante de la communauté. Cette envie de faire consensus. De toute manière, la multiplication des plugins fait le reste. Si telle ou telle personne préfère tel ou tel comportement qui semble bizarre au plus grand nombre, il lui suffit de faire son plugin et il aura son comportement. Pour lui et les quelques personnes qui pensent comme lui.

C'est ainsi que DHH explique dans son blog personnel, que Rails n'est pas DHH. Rails devient vraiment un consensus de rubyiste. La cible n'est pas d'avoir le meilleur framework web en Ruby. Mais d'avoir le meilleur framework en informatique. Combattre ensemble le Java, le .NET ou le PHP. Tous les développeurs ruby en sont persuadé, c'est évident. Mais tous les développeurs web ne sont pas rubyiste.

Pour ma part, j'ai étudier dernièrement Merb et j'en ai été très content. J'avais même commencer des projets open source en Merb. Après une longue réflexion j'ai décidé de continuer d'utiliser Merb sur ces projets qui était assez jeunes aurait très bien pu migrer facilement en Rails. Par contre, j'utiliserais DataMapper comme ORM et essayerais de contribuer à ce merveilleux projet. Qui lui finalement reçoit une grosse pub car il sera possible de l'utiliser dans Rails 3.

Pour les curieux, voici les logs de la soirée IRC sur le chan #merb où l'activité a été très intense après l'annonce sur merge.

Finalement, il ne faut avoir qu'un seul mot d'ordre, allez Rails 3 et Joyeux Noël.