ruby

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 ?

Oupsnow de Merb à Rails

Dernièrement, j'ai fini par me décider de migrer Oupsnow, de Merb à Rails.

Alors que je finissais une migration de SQL à MongoDB, j'en entame une nouvelle. Celle-ci beaucoup plus profonde.

La raison de ma migration ?

Rails 3. En effet, depuis Décembre 2008, soit presque un an, Merb s'est figé. Certain me diront que la communauté Merb est en train de revivre et c'est tout à fait vrai. J'en suis même ravi. Mais Merb a pris un immense retard en presque un an. Même si Rails n'a pas vraiment avancé dans sa version stable, sa version Edge a elle énormément avancée.

Voulant toujours tester les nouvelles technologies en Ruby, je voudrais tester Rails 3. Mais aucun système n'existe pour passer de Merb à Rails 3. Un rapide test m'a montré que la différence était par contre minime entre Rails 2.3.x et Rails 3. La migration de Rails 2.3.x à Rails 3 en sera donc d'autant plus simple.

Voulant vraiment sortir une version stable le plus vite possible, j'ai donc pris la décision de migrer Oupsnow vers Rails 2.3.x pour ensuite migrer sur Rails 3 pour cette fois sortir une version de Oupsnow compatible Rails 3.

Oupsnow devient donc un projet Rails/MongoMapper et non plus Merb/DataMapper comme sa dernière version. Toute aide est bien-sûr la bienvenue.

English translation

Le logger ruby avec son bloc

Alors que je m'amusais à étendre le Logger de base de Ruby, j'ai découvert que l'on pouvait utiliser le Logger comme ci-dessous :

Logger.debug { "My object is #{self.map(&:id)}" }

Par défaut, on l'utilise en fournissant une string en paramètre comme ceci : Logger.debug("My object is #{self.map(&:id)}").

La différence entre ces deux écritures ?

La première permet d'éviter d'évaluer la chaine qui sera loggé si elle n'en a pas besoin. Contrairement à la deuxième qui sera toujours évaluée même si vous ne la loggez pas. Ainsi le temps de traitement pourrais s'en faire ressentir.

Grâce à ça, on peux facilement éviter les fameux :

Logger.debug("My object is #{self.map(&:id)}") if Logger.level == Logger::DEBUG

En effet, ce genre de code est très fréquent en Java, pour gagner un petit peu en performance sans perdre ses logs.

Pourquoi Rspec au lieu de Test::Unit?

Dernièrement, on m'a posé la question toute bête :

Pourquoi Rspec au lieu de Test::Unit ?

C'est vrai que je suis un adepte de Rspec et que je n'utilise que ça si c'est possible. mais je n'ai jamais expliqué ici clairement ce qui me pousse dans ce choix. Donc voici un résumé très bref de mon choix.

Les formateurs

Une des options méconnues de Rspec est la possibilité de définir son formateur. Il existe ainsi plusieurs formateurs base. On peux ainsi avoir un retour direct sous format HTML ou text avec les points ( classique avec Test::Unit). Mais certain formateur peuvent aussi calculer le temps que dure un exemple. Ainsi nous avons une facilité de détection des test les plus lent pour les refactorer et essayer d'améliorer le temps de réalisation de ses tests. Dans ce sens, j'ai moi même créer mon propre formateur Rspec.

Les tests partagés

Rspec dispose d'une possibilité sous estimés, les tests partagés. En effet, on peux définir certain jeux de test comme "partageable" on a ainsi la possibilité de les incorporer facilement dans divers tests. C'est une fonction vraiment pratique dans le cadre de test fonctionnel principalement. Plus besoin de copier/coller son code. :)

Compatibilité Test::Unit

Le passage a Rspec est assez aisé de part sa compatibilité avec Test::Unit. En effet, si vous n'êtes pas familier ou que vous n'aimez pas la formalation my_array.should be_empty, rien ne vous y oblige. Vous pouvez tout à fait utiliser la syntaxe Test::Unit assert my_array.empty?. La migration s'en trouve très largement aisée.

l'OSDC.fr 2009, j'y serais

Le 2 et 3 Octobre aura lieu en première française, un rassemblement de codeur d'environnement différent, l'OSDC.fr. Cette conférence est organisé par les associations françaises de Ruby (RubyFrance), Python (AFPy) et Perl (Mongueurs de Perl). Mais ce ne seront pas les seuls langage qui seront présenté. On peux ainsi trouver des sujets sur du PHP.

En tout cas je suis très heureux de pouvoir y présenter une petite conférence sur Cucumber. J'espère vous y retrouver.

Open-notification v0.1.0 est sortie

Il y a maintenant un mois, j'ai commencé à jouer avec nanite. Pour essayer un peu cette technologie, j'ai réaliser une mini application en sinatra et un agent nanite qui envoi des notifications par Jabber.

De fil en aiguille, le code s'est agrémenté et est surtout passé à Merb avec un système de persistance en CouchDB.

L'idée de base est extrêmement simple, gérer plein de notification de tous type. Il existe déjà ce genre de système comme messagepub. Mais là ca sera open source.

Open notification sort donc en version 0.1.0 pour sa première version. Le code sera mis sous licence AGPLv3. Il est composé d'un agent nanite qui gére l'envoi des notifications jabber et d'une application avec Merb/CouchDB.

La méthode de déploiement est assez compliqué je l'avoue car il n'y a aucune documentation. Cela arrivera dans les prochaines versions.

Une version complête est utilisable par tout un chacun sur open-notification.com. Ce service n'a pour l'instant aucune pérennité. Mais on verra dans le futur ce que ca donnera.