Shiny happy people coding

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

cyril.mougel@gmail.com (Cyril Mougel) — Wed, 27 Jan 2010 23:47:00 +0100

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.

Que cherche un développeur dans une offre d'emploi ?

cyril.mougel@gmail.com (Cyril Mougel) — Sat, 23 Jan 2010 11:40:00 +0100

On m'a posé dernièrement cette question. Ça peut sembler bête au premier abord, mais après quelques secondes de réflexion on se rappelle que toutes les offres d'emplois sont pleines d'interrogation.

Donc qu'est ce que j'attends dans une offre d'emploi ?

Le nom de l'entreprise :

Le nom de l'entreprise est toujours pratique ne serait-ce que pour zapper l'annonce si on aime pas cette entreprise. Ou alors rigoler encore plus en lisant l'offre d'emploi.
Le cœur de métier de l'entreprise :

C'est toujours agréable de savoir si on va travailler pour une entreprise qui fait du beurre ou des sites Web. On peut ainsi éviter certains entretiens inutiles.
Le nombre de développeurs dans l'entreprise :

C'est une question plutôt inhabituelle pour un recruteur, mais avoir cette information permet de savoir tout de suite si on sera le geek dans son coin qui sera interrompu pour faire de l'assistance Words alors qu'il n'a plus touché à un windows depuis 3 ans. Au contraire, si on voit qu'il y a une majorité de développeurs, on pourra se dire que ça sera la fête aux trolls. Un développeur aime les Trolls \o/.
Les personnes connues :

Comme dans tous métiers, on connaît certaines personnes de réputation. Cela peut facilement aider un développeur à choisir cette offre d'emploi si une personne connue y est. En revanche, c'est aussi à double tranchant. Certains feront l'entretien juste pour voir cette personne. D'autres zapperont encore plus l'offre d'emploi à cause de cette même personne.
L'environnement de travail :

L'OS utilisé en majorité par les développeurs de la société peut être un très bon indicateur parfois. Typiquement chez AF83 où je travaille encore en ce moment, tous les développeurs sont sous UNIX, soit GNU/Linux, soit MacOSX. Pour beaucoup, cela prouve la qualité des développeurs. Et là encore la guerre aux trolls pourra facilement être ouverte.
La contribution Open source possible et faite par l'entreprise :

Avoir du temps pour faire de l'Open Source selon notre désir est un plus non négligeable selon moi. J'ai énormément de projets open source en cours que je fais en parallèle de mon emploi, mais si je pouvais les faire aussi durant une partie de celui-ci, je serais vraiment heureux. Ensuite le fait que la société produise du code Open Source, peut facilement permettre au développeur de jauger de la qualité du code de cette société. En effet, pourquoi est-ce toujours la société qui doit vérifier le code de ses futurs employés ?

Selon, moi ces 6 points ne sont hélas pas toujours renseignés dans une offre d'emploi et cela serait un plus non négligeable.

Sortie de Typo 5.4.0

cyril.mougel@gmail.com (Cyril Mougel) — Mon, 21 Dec 2009 21:30:00 +0100

Ç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

cyril.mougel@gmail.com (Cyril Mougel) — Tue, 01 Dec 2009 23:02:00 +0100

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 ?

cyril.mougel@gmail.com (Cyril Mougel) — Mon, 30 Nov 2009 22:58:00 +0100

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.

cyril.mougel@gmail.com (Cyril Mougel) — Thu, 19 Nov 2009 23:36:00 +0100

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

cyril.mougel@gmail.com (Cyril Mougel) — Wed, 18 Nov 2009 23:47:00 +0100

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 ?

cyril.mougel@gmail.com (Cyril Mougel) — Wed, 04 Nov 2009 22:53:00 +0100

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

Le logger ruby avec son bloc

cyril.mougel@gmail.com (Cyril Mougel) — Wed, 21 Oct 2009 23:08:00 +0200

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?

cyril.mougel@gmail.com (Cyril Mougel) — Sun, 04 Oct 2009 22:59:00 +0200

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.