Shiny happy people coding

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

RabbitMQ ne marche pas avec Mac OS ?

Il y a quelque semaine, alors que je me remettais tout simplement à l'utilisation de RabbitMQ, j'ai eu un gros problème. Alors qu'il faut configurer les vhost et les utilisateurs de RabbitMQ, impossible de contacter mon service rabbitMQ avec la commande rabbitmqctl. Prévoyant une migration vers Mac OS Snow Leopard et n'ayant pas un besoin urgent de RabbitMQ, j'ai repoussé la recherche du problème.

Mais voilà, maintenant que je suis sous Mac Os Snow Leopard, j'ai réinstaller RabbitMQ pour le réutiliser à nouveau. Et là, surprise toujours le même soucis. Après de longue recherche, je viens enfin de trouver la cause, le hostname.

Que faire si votre noeud de contrôle rabbitMQ n'arrive pas à discuter avec le noeud maitre ?

Très simple, faite un simple hostname -s et ajouter ce hostname en concordance de l'ip 127.0.0.1 dans votre fichier /etc/hosts. Ça y est tout fonctionne. C'est parfois tellement simple la résolution d'un problème.

English translation