Gestion des dépendances avec Merb

Utilisant de plus en plus Merb sur mon temps personnel et dans mes projets open source, j'ai dû étudier un peu plus profondément le système de dépendances de Merb.

Merb est par essence un framework basé sur les gems. Dans cette logique il pousse à n'utiliser que des gems et uniquement ceux ci.

Utilisation des gems avec Merb

Pour utiliser un gem avec Merb, rien de plus simple car tout est prévu pour. Que ce soit avec votre répertoire local de gem ou alors avec un freeze du gems.

Utilisation de votre répository gem local

Si vous ne voulez utiliser que cette technique, alors rien de plus simple, modifier le fichier /config/dependencies.rb pour indiquer les gems à charger dans votre application. Voici par exemple le fichier dépendencies.rb d'une application installer de frais.

# dependencies are generated using a strict version, don't forget to edit the dependency versions when upgrading.
merb_gems_version = "1.0.7.1"
dm_gems_version   = "0.9.8"

# For more information about each component, please read http://wiki.merbivore.com/faqs/merb_components
dependency "merb-action-args", merb_gems_version
dependency "merb-assets", merb_gems_version  
dependency "merb-cache", merb_gems_version   
dependency "merb-helpers", merb_gems_version 
dependency "merb-mailer", merb_gems_version  
dependency "merb-slices", merb_gems_version  
dependency "merb-auth-core", merb_gems_version
dependency "merb-auth-more", merb_gems_version
dependency "merb-auth-slice-password", merb_gems_version
dependency "merb-param-protection", merb_gems_version
dependency "merb-exceptions", merb_gems_version
 
dependency "dm-core", dm_gems_version         
dependency "dm-aggregates", dm_gems_version   
dependency "dm-migrations", dm_gems_version   
dependency "dm-timestamps", dm_gems_version   
dependency "dm-types", dm_gems_version        
dependency "dm-validations", dm_gems_version  

dependency "merb_datamapper", merb_gems_version
dependency "do_sqlite3" # If using another database, replace this

On y liste ainsi tous les gems de merb et Datamapper que l'on souhaite utiliser. Si on veux en utiliser de nouveau, il suffit d'en ajouter à cette liste. Vous pouvez aussi en supprimer de cette liste pour diminuer ainsi le nombre de gem chargé dans votre application.

Utilisation d'un repository de gems local à votre application

Voici un point qui différe grandement de RubyOnRails. Mais à mon sens, là encore il est beaucoup mieux conçu que Rails. En effet, l'idée est très simple. Rubygems permet de définir le dossier où se trouve vos gems. Pourquoi ce répertoire ne serait pas simplement dans votre application ?

Pour mettre en place cette technique, il faut au préalable créer le dossier /gems/ dans votre arborescence. Ensuite utiliser les tâches thor pour installer les gems que vous désirez directement dans votre nouveau répository gems. Ainsi pour installer merb-core et datamapper, il vous suffit de faire :

$ thor merb:gem:install merb-core dm-core

Une fois fait de même pour toutes vos dépendances. Vous avez freezé votre application avec tous les gems utilisés.

Si vous utilisez un gestionnaire de source, il faudra alors n'ajouter à votre repository que le dossier /gems/cache/ en effet, ce dossier contient les .gem que vous utilisez. Les autre dossiers seront générés. Ensuite si quelqu'un récupére vos sources, il lui suffira de réaliser la commande thor de redéploiement :

$ thor merb:gem:redeploy

Tous les gems dans le dossier cache seront ainsi installé dans votre dossier gems. Là où je trouve que ce système est meilleur que celui de Rails est que si vous avez un gem avec un extension C vous pouvez le freezer avec Merb. Chose que vous ne pouvez pas faire avec Rails.

Mais et si je veux utiliser les versions de développement ?

Voici selon moi le point faible de Merb face à Rails. En effet, avec rails, rien de plus simple. On met les sources dans le dossier /vendor/ soit /gems/ soit /plugins/ et roulez jeunesse, tout fonctionne sans changement. Un simple git-submodule permet de suivre l'évolution du tout. Mais Merb ne permet pas ça. Merb ne loadera que des gems et uniquement des gems.

Technique recommendée par la core-team

La technique que finalement la core-team recommende est encore une fois de se baser sur les gems. Pour cela, rien de plus simple, il suffit de créer le gem correspondant à votre version de développement, l'ajouter dans le dossier gems/cache et ainsi l'utiliser. Des tâches utilitaires existent pour aider à tout ça. Par exemple pour installer la version de développement de Datamapper, vous pouvez faire :

$ thor merb:source:install dm-core

Cette tâche créera un clone du repository dm-core dans votre dossier /src/, générera le gem et installera dans votre dossier /gem/. Vous pouvez aussi faire de même en installant les sources directement dans le dossier /src/ et utiliser le nom de votre dossier. Ca lancera la tâche rake package et installera le gem généré.

Ce que je trouve dommage avec cette technique est l'impossibilité de savoir réellement quel est la version utilisée. En effet, gem utilise un numéro de version fixe et on n'a pas forcement l'information du commit qui a généré ce gem. J'aime bien pouvoir juste en clonant un projet savoir exactement la source exact du gem que j'utilise. Donc soit sa version, soit son numéro de commit.

Ma technique pour permettre de contourner le problème

La technique que j'ai ainsi trouvé fonctionne, mais n'est hélas pas complétement optiminum. Dans mon fichier config/init.rb, j'ai créé une petite méthode :

def load_from_source(src)
  $:.unshift File.join(Merb.root, "src/#{src}/lib")
  require "src/#{src}/init.rb"
end

Ensuite dans le callback before_app_loads, j'ai pu faire appel à ma méthode

Merb::BootLoader.before_app_loads do
  # This will get executed after dependencies have been loaded but before your app's classes have loaded.
  load_from_source('will_paginate')
end

Avec un clone du repository will_paginate dans mon dossier /src/ will_paginate est ainsi chargé automatiquement avant le load de l'application et après le load de toutes les dépendances.

Par contre cette technique à un gros défaut que je n'ai pas réussi à palier sauf en proposant un patch à Merb (ce que je ferais peut-être, même si Merb en tant que tel est mort :'(). En effet, on ne peux loader à partir des sources qu'après le load des dependancies. Si vous voulez loader au milieu des dépendances, vous ne pouvez pas. Il faudra obligatoirement passer par le système des gems.

Ce qu'il ne faut pas faire

Je vous rassure, je l'ai fait, ce qui me permet de vous dire de ne pas le faire. Ainsi, il ne faut pas ajouter le require directement dans le dependencies.rb. En effet, le chargement des dépendences ne se fait pas à ce moment là. Ce n'est qu'un chargement d'une liste gems à charger. Si vous faites votre require à ce moment vous pourrez ainsi vous retrouver avec des problèmes d'ordre de chargement.

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.

Envoyer un email dans un model DataMapper

Avec Merb-mailer, merb fourni un système d'envoi d'email. Par contre merb étant un framework web se voulant ORM agnostique, merb-mailer est considéré comme un controller et non comme un model. De ce fait l'utilisation de la méthode send_mail n'est disponible que dans les controllers. Mais alors comment utiliser la méthode send_mail dans son model ? C'est très simple. Là encore merb utilise un système entièrement ruby ce qui facilite le méchanisme

Après une courte recherche dans le code de merb-mailer, j'ai pu constater que que la commande send_mail était dans un mixin. l'inclusion de ce mixin suffit donc à avoir la commande pour l'utiliser.

class Member
  include DataMapper::Resource
  include Merb::MailerMixin

  property :id, Serial
  property :name, String

  def register
    // some code
    send_mail (UserMailer, :register, {
        :from => "no-reply@example.com",
        :to => person.email,
        :subject => "Please activate your account" 
    }
  end

English translation

Les named_scope en pratique sur une recherche

J'ai longtemps été sceptique sur l'intérêt des named_scope de Ruby On Rails. Ça permet d'avoir une lecture plus simple. Mais ne voyant pas un système d'eager loading si on ne les utilisait pas immédiatement, je trouvais cela dommage. Finalement après une grosse recherche, j'ai fini par en créer un exemple que je pense vraiment intéressant d'utilisation des named_scope. La mise en pratique a eu lieu sur Typo avec un commit de refactoring. Voici donc un extra de code qui parle de lui même.

class Article

   named_scope :published_at_like, lambda {|date_at| {:conditions => ['published_at LIKE ? ', "%#{date_at}%"]}}
   named_scope :user_id, lambda {|user_id| {:conditions => ['user_id = ?', user_id]}}
   named_scope :published, {:conditions => ['published = ?', true]}
   named_scope :not_published, {:conditions => ['published = ?', false]}
   named_scope :category, lambda {|category_id| {:conditions => ['categorizations.category_id = ?', category_id], :include => 'categorizations'}}
   named_scope :draft, {:conditions => ['state = ?', 'draft']}
   named_scope :no_draft, {:conditions => ['state <> ?', 'draft'], :order => 'created_at DESC'}
   named_scope :searchstring, lambda {|search_string|
     tokens = search_string.split.collect {|c| "%#{c.downcase}%"}
     {:conditions => [(['(LOWER(body) LIKE ? OR LOWER(extended) LIKE ? OR LOWER(title) LIKE ?)']*tokens.size).join(' AND '),
                       *tokens.collect{ |token| [token] * 3 }.flatten]}
   }

   def self.search_no_draft_paginate(search_hash, paginate_hash)
      list_function  = ["Article.no_draft"]
      if search_hash.nil?
        search_hash = {}
      end
      
      if search_hash[:searchstring]
        list_function << 'searchstring(search_hash[:searchstring])'
      end
      
      if search_hash[:published_at] and %r{(\d\d\d\d)-(\d\d)} =~ search_hash[:published_at]
        list_function << 'published_at_like(search_hash[:published_at])'
      end
      
      if search_hash[:user_id] && search_hash[:user_id].to_i > 0
        list_function << 'user_id(search_hash[:user_id])'
      end
      
      if search_hash[:published]
        list_function << 'published' if search_hash[:published].to_s == '1'
        list_function << 'not_published' if search_hash[:published].to_s == '0'
      end
      
      if search_hash[:category] and search_hash[:category].to_i > 0
        list_function << 'category(search_hash[:category])'
      end
      
      paginate_hash[:order] = 'created_at DESC'
      list_function << "paginate(paginate_hash)"
      eval(list_function.join('.'))                                                                                        
    end

Par contre si vous avez encore une meilleur méthode, je suis preneur. C'est surtout le eval qui m'embête un peu :(

La Rails party fini, voici les slides

La Rails party est désormais fini. Comme prévu, j'y ai fait 3 présentations. Je vous joins ici les PDF de ces présentations sous licence CC

• Initiation à Rails et Rspec
• Migration d'une application de Rails 2.0 à Rails 2.2 avec Typo comme exemple
• Présentation de Pictrails

Cette après midi a vraiment été très enrichissante. Énormément de bonne présentation. Quand on sait que tout cela a été réalisé en presque seulement 6 semaines, un grand chapeau au vice-président de RubyFrance Jean-François Trân.

Grâce à cet évènement, j'ai pu découvrir un peu plus en profondeur la communauté Rails. Elle est vraiment très enrichissante. Beaucoup de discussion se sont engagées toutes plus intéressantes les une que les autres. Vivement que l'on se retrouve tous à nouveau. On pourra coder encore plus de Typo :)

Ma technique pour suivre twitter

Ce soir durant l'apéro ruby, j'ai expliqué ma technique personnel pour suivre twitter. Il doit y avoir autant de technique que d'utilisateur mais je vous explique la mienne.

Premièrement, il faut utiliser le gem twitter. Ce gem fourni un petit binaire qui permet de poster et vérifier les updates sur son compte twitter. Couplé à une base de donnée en SQLITE, il nous informe que des nouveaux updates.

Enfin, il suffit de coupler ce gem avec un cron en un pipe sur mail pour pouvoir récupérer régulièrement les updates dans sa messagerie mail. Comme dirais Jean-François Tran, je suis un pro-logger. Je log tout. Mais bon, ça me permet de suivre plus facilement une longue liste d'update de tweet avec un mail par heure.

Voici ma ligne cron :

42 * * * * twitter timeline | mail -s 'twitter timeline' cyril.mougel@gmail.com

Simple et efficace. Pourquoi s'encombrer avec OSX :p

l'upcase d'accent c'est possible avec ActiveSupport

Alors que sur IRC quelqu'un demande, comment faire un upcase sur des accents et conserver ces accents en majuscule, je lui répond que ce n'est pas possible car Ruby 1.8 ne supporte pas l'UTF8.

Je propose donc une solution peu élégante. Lister chaque éléments qui soient considéré comme non modifié par upcase et faire une liste de gsub comme ceci

irb(main):002:0> puts "aéèb".gsub("é", "É").gsub("è", "È").upcase
AÉÈB
=> nil

C'est alors que Farzy nous fournit un bout de code qui évite mon code peu pratique et surtout fonctionne avec tous les caractères unicode.

% irb
>> $KCODE = 'u'
=> "u"
>> "éè".upcase
=> "éè"
>> require 'activesupport'
=> true
>> "éè".chars.upcase.to_s
=> "ÉÈ"
>> RUBY_VERSION
=> "1.8.5"
>>

Il faut effectivement utiliser la librairie ActiveSupport qui fournit un support UTF8, mais cela fonctionne parfaitement. Merci à lui pour cet petite astuce.

je suis devenu contributeur Rails

Depuis maintenant 8 jours, j'ai eu la chance de voir un de mes patchs intégrés dans Rails. Ainsi depuis ce commit, je peux dire que j'ai contribuer à Rails \o/