ruby

# This file allows for the running of rubygems with a nice
# command line look-and-feel: ruby -rubygems foo.rb

Sortie de Capistrano 2.0

Dans un billet très récent, j'avais parlé des nouveautés de Capistrano 2 indiquant sa sortie très proche. Et bien il est sorti le lendemain de mon post, le 20 Juillet 2007. En effet, il a été taggé dans le dépôt SVN. Sur le site officiel de Capitrano, il n'est pas encore complétement marqué comme étant la version stable. Mais je pense que cela sera mis à jour très prochainement.

Pour toutes mises à jours de Capistrano pensez à regarder la documentation de mise à jour. Pour tous les nouveaux projets, pensez à utiliser directement Capistrano 2 qui est beaucoup plus évolué que ca première version.

Les nouveautés de capistrano 2

Aujourd'hui, je viens de lire une présentation sur les nouveautés qu'apportent capistrano dans sa version 2. Je suis complétement bluffé. j'ai juste utilisé un peu capistrano dans sa première version et j'avais trouvé ça vraiment très interressant et j'avais constaté que ca permettais beaucoup de chose. Là avec cette nouvelle version, on peux faire encore plus de chose et ça permet d'administrer plusieurs machine en même temps. On pourrait presque l'utiliser pour faire des checks sur plusieurs machine en parallèle sans ouvrir plusieurs shell.

La fonctionnalité qui m'a le plus impressionner et le fait de lancer la même commande sur plusieurs host en parallèle et voir la sortie de chacun. Je vais donc faire une migration immédiate sur capistrano 2 et arreter d'étudier capistrano 1. Autant prendre tout de suite les devants.

Par contre c'est vrai que son utilisation est surtout nécessaire dans un environnement clusterisé avec plusieurs machine. Dans un contexte avec une seule machine, ca sert beaucoup moi dû fait des tâches rake. Mais quand même c'est vraiment génial.

Nouveau converter de Dotclear vers Typo

Ma migration vers un blog sous Typo approchant et étant actuellement, sous Dotclear, j'ai créé un nouveau plugin pour Typo. Ce plugin est une copie du converter de Mephisto pour Typo. En effet, le système de conversion de Mephisto me semble beaucoup plus performant et plus adapatable que celui de Typo. Typo étant un projet libre, j'ai donc créer un ticket pour proposer mon patch. J'attend de voir la réaction des développeurs sur ce plugins. Le ticket de submission est le ticket 1132.

Je vais vous faire la traduction de mon mauvais anglais.

J'ai créer un nouveau système pour convertir la base de donnée d'un autre blog en en base de donnée Typo. Mon nouveau système est basé sur le converter de Mephisto. C'est un plugin et il utilise complétement ActiveRecord. Pour récupérer les informations d'un autre blog et les poster dans Typo.

Actuellement le converter fonctionne uniquement avec Dotclear, mais une interface est écrite et vous pouvez l'utiliser pour d'autre moteur de blog en créant un autre adapter.

Pour commencer la migration de dotclear, vous avez besoin de compléter le config/database.yml avec une configuration qui a pour clé dv and toutes les information sur où trouver la base de donnée récupérer par un SQLDump de votre moteur de blog. Après cette configuration vous pouvez commencer la migration avec la commande suivante :

./script/runner 'TypoPlugins.convert_from :dotclear'

Par défaut vous pouvez migrer tous les articles, mais vous pouvez aussi migrer uniquement les articles de catégories défini.

./script/runner "TypoPlugins.convert_from :dotclear, {:categorie => ['ruby', 'rails', 'dev']}"

Conseil : Pour accélerer grandement la migration vous pouvez commenter la ligne suivante dans le config/environement.rb

#config.active_record.observers = :email_notifier, :web_notifier

Edit : 10min avant la soumission de mon patch, le script de migration disponible sur RubyFR avait été mis à jour. Quel hasard. L'annonce de cette mise à jour

et pourquoi pas avec around_filter ?

Après encore de petites recherches, j'ai fini par trouver une méthode encore plus propre. Cette méthode est tout simplement basé sur le filter around_filter. Ce filtre est tout bête et totalement génial. Il permet de réaliser des traitements avant et après ton controller. Mais bien sûr après et avant les filtres de before_filter et after_filter. On peux ainsi mettre notre profiler directement dans cette méthode. Voici un exemple de code qu'on peut utiliser cette fois ci avec le profiler ruby-prof.

class MyController < ApplicationController
  around_filter(:only => :my_method) do |controller, action_block|
    require 'ruby-prof'
    RubyProf.clock_mode = RubyProf::WALL_TIME
    RubyProf.start
    action_block.call
    results = RubyProf.stop
    printer = RubyProf::FlatPrinter.new results
    printer.print(STDOUT, 0)
  end

  def my_method
     #implement this method
  end
end

Faire un profil d'une méthode de "controller" Rails

Je me suis retrouvé confronter à une méthode d'un "controller" de Ruby On Rails que je trouvais particulièrement longue sachant qu'elle faisait plus d'une seconde et que ce n'était ni le temps du "render", ni le temps de la Base de donnée. La meilleure méthode pour optimiser ce genre de méthode, c'est tout simplement de faire un profile du traitement effectué. Mais voilà, comment faire un profile ?

Et bien c'est très simple, il faut utiliser le profiler Ruby (disponible avec le require 'profiler'). Un fois le require effectué un Profiler__::start_profile, puis un Profiler__::stop_profile englobe le code a profiler. Enfin un Profiler__::print_profile STDOUT permet une sortie du profil dans le STDOUT. Ce qui permet ainsi d'être utilisé comme cela dans notre "controller".

require 'profiler'
class MyController < ApplicationController
  def my_method
    Profiler__::start_profile
    
    # Mon code à profiler

    Profiler__::stop_profile
    Profiler__::print_profile STDOUT
  end
end

Après une petite étude du code du script de "profiler" fournit par rails dans /script/performance/profiler, j'ai pu constater qu'il existait une gem permettant d'améliorer le "profiling" avec un "profiler" plus rapide et de plus belle sortie, en autre en HTML. Il s'agit de ruby-prof. L'utilisation est là même que précédemment, c'est juste les appels qui sont différent.

Sortie unique de rails-computer-checker en version 0.1.0

Pour l'école, j'ai du réaliser avec d'autres personnes une application web compléte en Ruby On Rails. Cette application permet de gérer un parc informatique avec gestion d'incidents reportés par un petit script qui tourne sur les machines. Ne voulant pas trop que mon projet reste à jamais inutilisé, j'ai tout mis en place sur un projet code.google. Je ne pense pas maintenir ce projet . Donc si par le plus grand des hasards un mainteneur se présente, il n'y a pas de souci pour que je lui donne un accès.

J'ai fait une release d'un version que j'appelle 0.1.0 qui est la version présentée à notre professeur.

Nouvelle tâche rake sur Rails : rake routes

Voici une nouvelle tâche rake qui a été ajouté à Rails à partir de la révision 7149, suite au ticket #8795. Je trouve cette tâche assez intéressante pour la blogger et en parler. Grâce à elle on arrivera à retrouver très rapidement toutes les routes que nous avons défini. Ca sera vraiment très pratique pour lire un code existant et retrouvé des routes.

Si par hasard vous souhaitez déjà l'utiliser, c'est assez facile. il suffit de récupérer le fichier routes.rake sur le trunk et le mettre dans son projet dans votre dossier /lib/tasks/. Immédiatement vous pourrez le tester avec un petit rake routes. J'adore.

Ajouter des Headers HTTP dans ses réponses Rails

Actuellement à fond sur mon projet Rails pour l'école, je me suis heurté à un problème tout bête et je n'ai trouvé aucune documentation complète sur l'API de Rails. En effet, je voulais renvoyé un status 201 et un header HTTP 'Location'. Dans un premier temps, j'arrivais à faire l'un ou l'autre, mais pas les deux. Le status 201 avec un render :nothing => true, :status => 201, ou le Header Location avec un redirect_to, mais qui envoyait un status 302.

C'est alors que je me suis penché un peu plus sur le code même de rails et encore une fois, il ne faut surtout pas hésiter à mettre les mains dans le camboui.J'ai ainsi découvert l'utilisation des objets response et request disponible directement dans notre controlleur. Ainsi avec un simple :

response.headers['Location'] = 'new/url'

Nous pourrons constater dans notre réponse HTTP l'information suivante : Location : 'http://localhost:3000/new/url'

Each vs For

En codant avec un ami, je lui ai fait la réflection qu'en ruby, il était plus rubyiesque d'utiliser le système de block et la méthode each sur un list plutôt que d'utiliser une boucle for à la Java comme il voulait le faire.

Partant de cette interrogation, je me suis demandé quel pouvait bien être la méthode réellement la plus rapide ?

Pour tester ce genre d'allégation, rien de mieux qu'un petit script ruby et un bon benchmark pour être sûr de ce qu'il en est réellement. J'ai donc utilisé le script suivant pour faire mon benchmark :

#! /usr/bin/ruby -w

require 'benchmark'

a = 1
n = 5_000_000
b = []
n.times { b << a; a+= 1;}
Benchmark.bmbm(10) do |x|
  x.report("each{}") { b.each { |r| r + 1}}
  x.report("each do end") {b.each do |r| r + 1; end}
  x.report("for do end") {for r in b do r + 1; end}
end

Voici les résultats que j'ai obtenu :

Sur un INSPIRON 1300 avec les caractéristiques suivantes :

• Processeur : Intel(R) Pentium(R) M processor 1.70GHz
• Memoire RAM : 508636 kB
• Distribution : Debian/Linux
• ruby : ruby 1.8.6 (2007-03-13 patchlevel 0) [i486-linux]

concerto-linux-15:06:50:~$ ./bench_boucle.rb 
Rehearsal -----------------------------------------------
each{}        5.060000   1.060000   6.120000 (  6.584567)
each do end   5.140000   0.980000   6.120000 (  6.149548)
for do end    4.620000   1.060000   5.680000 (  5.720802)
------------------------------------- total: 17.920000sec

                  user     system      total        real
each{}        5.030000   1.080000   6.110000 (  6.542022)
each do end   5.020000   1.100000   6.120000 (  6.137550)
for do end    4.600000   1.080000   5.680000 (  5.700844)

Sur un HP Pavilion ze4900 avec les caractéristiques suivantes :

• Processeur : Intel(R) Pentium(R) M processor 1.50GHz
• Memoire RAM : 481108 kB
• Distribution : Gentoo/Linux
• ruby : ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-linux]

shingara@shalamarette ~ $ ./bench_boucle.rb 
Rehearsal -----------------------------------------------
each{}        2.900000   0.000000   2.900000 (  2.897030)
each do end   2.840000   0.000000   2.840000 (  2.873575)
for do end    2.360000   0.010000   2.370000 (  2.355282)
-------------------------------------- total: 8.110000sec

                  user     system      total        real
each{}        2.870000   0.000000   2.870000 (  2.876499)
each do end   2.870000   0.000000   2.870000 (  2.882328)
for do end    2.350000   0.000000   2.350000 (  2.747947)

Finalement en regardant ces résultats, nous pouvons constater que la méthode la plus rapide semble être le for, alors que c'est vrai que ma première impression aurait été que le each serait plus rapide que le for. Une fois de plus, il n'y a vraiment que les test qui permettent de savoir exactement ce qui est plus ou moins rapide.

L'autre petite remarque que nous pouvons faire sur ce benchmark est la différence entre {} ou le do end. En effet nous pouvons constater qu'il n'y a absolument aucune incidence sur la performance. Cela ne sert vraiment qu'à la priorisation de l'un par rapport à l'autre.