City.create :name => "Paris"
City.create :name => "New-York"

Après avoir joué quelque peu avec cette commande, on constate qu'elle souffre d'un grand défaut : étant un script ruby, des exécutions multiples risquent de créer les données de base à chaque exécution. Il est toujours plus agréable et moins risqué de ne pas avoir à réfléchir à l'état ou le contenu de sa base de données avant d'exécuter une tache. L'idée ici est de remplacer les create par des find_or_create évitant de doubler les données.

%w{Paris New-York}.each {|city_name| City.find_or_create_by_name city_name}

On peut aussi perfectionner la chose en autorisant la mise à jour de ces données primaires avec le script de seeds :

cities = {
  "Paris" => {
    :country => "France",
    :zipcode => "75000"
  },
  "New-York" => {
    :country => "USA",
    :zipcode => "10001"
  }  
}

cities.each do |city_name, city_infos|
  city = City.find_or_initialize_by_name city_name
  city.update_attributes city_infos
end

Ainsi, à chaque appel de la rake task, les données seront soit crées si non présentes soit mises à jour, sans avoir à se préocuper de l'état de la base.

Toujours dans l'idée de simplifier les choses et minimiser les interventions humaines (et les erreurs potentielles), on peut lancer cette rake task à chaque déploiement en production : un simple ajout dans le script de déploiement capistrano fait l'affaire.

namespace :deploy do
  namespace :database do
    desc "Load seed data"
    task :seed, :roles => :db, :only => { :primary => true } do
      run "cd #{current_path} && rake db:seed"
    end
  end
end

after "deploy", "deploy:database:seed"

On transforme donc le simple script d'initialisation d'application en outil léger de maintenance de données systèmes, simplifiant le déploiement et le développement quotidien.

Si vous regardez le nom du fichier, on trouve la racine 'hero' : http://images.apple.com/quicktime/qtv/specialevent0110/images/hero20100127.jpg

En poussant un peu plus loin, l'élément alt de la balise html image contient la chose suivante :

Silhouette of person dancing with an iPod.

On notera la petite erreur sur le nom de l'engin. Vu les pubs passées concernant l'iPod présentant des danseurs en ombre sur fonds colorés, on sent le copier/coller un peu rapide.

Décidant tout de même de tester une de ces librairies (rubyzip), je me suis posé la question des performances de ces librairies en comparaison d'une implémentation en C. Etant donné que je n'ai que l'archivage d'un répertoire à effectuer, sans contrôle d'erreur fin, pourquoi ne pas créer l'archive en passant par un bon vieux binaire zip disponible de facto sur pratiquement tous les systèmes.

J'ai donc pris des conditions simples : 4 fichiers, 2 textes (un readme et un code source c++) et 2 binaires (image jpeg et pdf). La librairie ruby benchmark pouvant comptabiliser le temps écoulé pour exécuter un block, il ne reste plus qu'à écrire le test.

require 'benchmark'
require 'rubygems'
require 'zip/zip'

Benchmark.bm(10) do |x|

  1.upto(10) do  
    x.report("rubyzip") do  
      FileUtils.rm_f "/tmp/rubyzip_test.zip"
      Zip::ZipFile.open("/tmp/rubyzip_test.zip", Zip::ZipFile::CREATE) do |zipfile|
        zipfile.add("tmp/files_to_zip/README",             "/tmp/files_to_zip/README")
        zipfile.add("tmp/files_to_zip/trombinoscope.pdf",  "/tmp/files_to_zip/trombinoscope.pdf")
        zipfile.add("tmp/files_to_zip/test3_1.jpg",        "/tmp/files_to_zip/test3_1.jpg")
        zipfile.add("tmp/files_to_zip/cpp_challenge.cpp",  "/tmp/files_to_zip/cpp_challenge.cpp")
      end
    end
  end
  
  1.upto(10) do  
    x.report("zip") do  
      FileUtils.rm_f "/tmp/zip_test.zip"
      `zip /tmp/zip_test.zip \
            /tmp/files_to_zip/README \
            /tmp/files_to_zip/trombinoscope.pdf \
            /tmp/files_to_zip/test3_1.jpg \
            /tmp/files_to_zip/cpp_challenge.cpp`
    end
  end
  
end

Très simplement, ce script va créer la même archive zip dix fois de suite en utilisant l'implémentation purement ruby : rubyzip. Une autre archive zip sera par la suite créée aussi dix fois de suite, cette fois-ci en exécutant la commande zip. Sur mon système, il s'agit de l'implémentation libre provenant de info-zip, dernière version en date : Zip 3.0 (July 5th 2008). Du côté ruby, nous avons un ruby branche 1.8.7 (2009-06-12 patchlevel 174) avec la librairie rubyzip 0.9.1.

Les résultats sont clairs :

                user     system      total        real
rubyzip     1.030000   0.080000   1.110000 (  1.354941)
rubyzip     1.020000   0.080000   1.100000 (  1.333094)
rubyzip     1.030000   0.080000   1.110000 (  1.410450)
rubyzip     1.020000   0.070000   1.090000 (  1.400208)
rubyzip     1.020000   0.080000   1.100000 (  1.421957)
rubyzip     1.010000   0.080000   1.090000 (  1.367412)
rubyzip     1.010000   0.080000   1.090000 (  1.488286)
rubyzip     1.010000   0.070000   1.080000 (  1.388657)
rubyzip     1.010000   0.080000   1.090000 (  1.388629)
rubyzip     1.000000   0.070000   1.070000 (  1.377627)
zip         0.000000   0.010000   0.870000 (  1.041277)
zip         0.000000   0.000000   0.870000 (  1.122224)
zip         0.000000   0.000000   0.870000 (  1.121751)
zip         0.000000   0.000000   0.870000 (  1.116203)
zip         0.000000   0.000000   0.880000 (  1.176530)
zip         0.000000   0.010000   0.880000 (  1.219610)
zip         0.000000   0.000000   0.870000 (  1.122010)
zip         0.000000   0.010000   0.880000 (  1.121724)
zip         0.000000   0.000000   0.870000 (  1.120681)
zip         0.000000   0.000000   0.880000 (  1.122107)

Même si l'appel au binaire zip nécessite l'ouverture d'un pipe, son exécution reste néanmoins moyennement 20% plus rapide que l'utilisation de la librairie purement ruby. Il est aussi interessant de noter que cette librairie ne semble pas avoir été écrite avec des considérations de performance fortes en tête et qu'elle n'est plus maintenue depuis bientôt 2 ans alors que ruby a beaucoup évolué sur la même période.

Mais l'interface fournie par rubyzip est très facile à utiliser et offre bien plus que ce qu'on peut obtenir avec l'exécution d'une commande externe. Comme par exemple la possibilité d'ajouter un fichier à l'archive à partir d'un flux. De plus, certaines contraintes d'hébergement empêchent parfois d'ouvrir un pipe pour exécuter une commande externe. Reste à savoir si ces apports et ornements sont vraiment utiles à votre besoin et valent les 20% de performance perdue.

Rails::Initializer.run do |config|
  # Some other stuff
  config.gem "flickraw", :lib => false
end

La phase d'authentification se fait en plusieurs étapes : obtenir un identifiant (frob) de flickr, rediriger l'utilisateur sur le site de flickr avec ce frob pour lui demander d'autoriser notre site à accéder à ses donnés, et enfin le retour de l'utilisateur de flickr sur notre site avec une valeur de frob modifiée nous permettant d'obtenir un token plus définitif.

require 'flickraw'

class FlickrController < ApplicationController
  before_filter :login_required

  # Redirect user to flickr
  def authenticate
    redirect_to FlickRaw.auth_url(:frob => current_user.flickr.auth.getFrob,
                                  :perms => 'read')
  end

  # User returns from flickr with a frob used to generate an authentication token
  def callback
    response = current_user.flickr.auth.getToken(:frob => params[:frob])
    current_user.update_attributes :flickr_token => response.token
  rescue FlickRaw::FailedResponse => e
    render :text => "Auth failed with #{e}"
  end
end

Si vous avez lu attentivement le code précédent, vous avez du remarquer la méthode flickr sur l'user authentifié fourni par restful_authentication (current_user). Il s'agit d'un petit détournement de la librairie flickraw qui est à la base 'mono-utilisateur' : la librairie ajoute une méthode flickr a la classe Kernel lui permettant ainsi d'être facilement accessible. Le problème vient dès lors que l'on est authentifié : n'ayant qu'une seule instance de flickraw avec son token d'authentification, il est impossible de gérer plusieurs utilisateurs. Il nous faut de plus une colonne token de type String pour stocker le token retourné par flickr.

C'est pourquoi on instancie un client flickraw par utilisateur, au niveau du modèle :

require 'flickraw'

class User < ActiveRecord::Base

  def flickr
    @flickr ||= FlickRaw::Flickr.new(self.token)
  end
end

Si le token est déjà présent (utilisateur ayant déjà authorisé le site), on a alors un client flickraw pouvant accéder directement aux photos. Sinon, on a une simple instance flickraw nous permettant de nous authentifier. L'autre avantage est aussi de nous donner l'accès au compte flickr de l'utilisateur dès lors qu'on instancie la classe : il n'est donc pas nécessaire d'être dans une réponse web classique pour accéder à ces photos, on peut aussi le faire dans un mécanisme séparé comme une tache de fond.

Récupération des sets de photo :

@user.flickr.photosets.getList.each do |flickr_set|
  puts "#{flickr_set.title} => #{flickr_set.description}"
end

Une dernière étape est nécessaire pour spécifier la clé ainsi que le secret pour accéder à l'API flickr : la librairie flickraw va chercher une constante FlickRawOptions avec des options globales. J'ai donc ajouté le fichier flickraw_options.rb dans les initializers (config/initializers/flickraw_options.rb), les 2 constantes FlickrKey et FlickrSecret étant définies spécifiquement dans chaque environnement pour avoir des clés d'API séparés pour le développement et la production :

FlickRawOptions = {

  'api_key'       => FlickrKey,
  'shared_secret' => FlickrSecret,

  'lazyload'      => true
  
}

Le côté réflection de l'Objective-C est fourni à travers la class NSObject, classe racine de toutes les autres classes. La lecture de la documentation de cette classe peut fournir des éléments intéressants, comme les méthodes permettant de déterminer la classe ainsi que la classe parente : class et superclass.

L'équivalent de method_missing est ici représenté par 2 fonctions : resolveClassMethod et resolveInstanceMethod qui sont appelées quand une fonction n'a pas été trouvée lors d'un appel, respectivement à la classe et à l'instance. Elles prennent toutes les deux comme paramètre le sélecteur (SEL) appelé et retournent un booléen (BOOL) indiquant si la méthode demandée à été ajoutée ou non.

La seconde partie importante dans l'ajout de méthode est l'appel permettant effectivement d'ajout cette méthode : class_addMethod. Elle prend comme paramètres la classe recevant la nouvelle méthode, le nom de la méthode, son implémentation ainsi qu'un array définissant les types d'arguments acceptés par la méthode.

ajout de méthode d'instance

Ayant besoin d'effectuer un traitement intermédiaire toujours identique avant de set/get des éléments d'une de mes classes, j'ai préféré utiliser cette méthode de résolution et d'ajout dynamique. Une implémentation simple est par exemple :

+ (BOOL) resolveInstanceMethod:(SEL)sel
{
  // Check if implementation is available in parent class
  if ([super resolveInstanceMethod:sel])
    return YES;
  
  // If not, add our method, returning add result
	if ([NSStringFromSelector(sel) hasPrefix:@"set"])
    return class_addMethod([self class], sel, (IMP)dynamicTransitorySetter, "v@:@");
  else
    return class_addMethod([self class], sel, (IMP)dynamicTransitoryGetter,"@@:");
}

static id dynamicTransitoryGetter(id self, SEL sel)
{
  return @"something else";
}

static void dynamicTransitorySetter(id self, SEL sel, id value)
{
  // Make with value
}

L'idée est ici assez simple : en fonction du selecteur passé, on va ajouter une méthode dynamiquement prenant certains paramètres. On peut ainsi spécifier toute une variété de paramètres acceptés par la méthode ajoutée. Dans le cas présent : v@:v est décomposé en v pour void, @: pour le selecteur et le charactère final @ correspond au paramètre accepté par la méthode. Quand à @@:, le premier @ correspond au type retourné, ici id, le @: restant correspond au selecteur.

ajout de méthode de classe

L'ajout de méthode d'instance est presque trivial, mais l'ajout de méthode de classe utilisant le même appel class_addMethod, il faut jouer un peu plus avec ce que nous offre l'Objective-C.

Nous avons ajouté simplement notre méthode d'instance à notre classe en précisant que la destination était l'objet \[self class\], représentant l'objet de la classe. Comme tout est objet ou presque en Objective-C, une classe est elle-même une instance de Class, avec comme méthode les méthodes d'instance définie dans la classe. Les méthodes de classe sont quand à elles stockées dans un autre objet : la metaclasse.

Un appel à objc_getMetaClass nous permettant de récupérer la metaclasse, le reste est identique à l'ajout de méthode d'instance :

Class metaClass = objc_getMetaClass([[self className] UTF8String]);
class_addMethod(metaClass, aSEL, (IMP)dynamicSomething, "v@:");

Dans un premier temps, il ne faut pas oublier 2 choses : flickr offre une API très bien construite permettant ce genre de chose et ruby de part son dynamisme permet de l'utiliser pleinement.

Concrêtement, on va distinguer 3 cas de réponse : une erreur, un objet ou une liste d'objet. Chaque réponse à sa classe propre : FailedResponse, Response et ResponseList. Armé de ces 3 type de réponse, la quasi-totalité des réponses faites par flickr peuvent être gérées.

La seconde partie concerne les requêtes : une simple classe Request fera l'affaire. Un appel sur l'API flickr à flickr.reflection.getMethods nous retournera une liste de tous les appels possible. Il ne reste plus qu'a lier ces appels à des méthodes crées dynamiquement. Pour chaque appel de la liste, une méthode d'instance est ajoutée à la classe Request, prenant des arguments qu'elle passe directement à une méthode générique chargée de l'appel a flickr, parsing et création de la réponse adéquat.

Cependant, afin de gérer les appels du type flickr.photosets.getList, il est nécessaire d'avoir un mécanisme de proxy (photosets) qui sera uniquement chargé de transmettre l'appel (getList). Ce système est assuré en créant, lors du parcours des appels flickr, un getter prenant dans le cas présant comme nom photosets et qui sera, lors de l'instanciation de la classe, initialisé avec une instance de Request. Cette instance, ayant reçu dynamiquement la méthode getList, est capable d'exécuter la méthode.

Les seules parties spécifiques et les plus longues de la librairies concernent l'upload, l'authentification et la signature des requêtes. Le reste est géré totalement dynamiquement par la création dynamique de méthodes et accesseurs.

Flickraw : une belle réalisation technique démontrant le potentiel de ruby et une implémentation flickr presque toujours à jour sans modification, ne demandant comme documentation que l'officielle de l'API flickr.

Après quelques recherches, j'ai pu trouver un tutoriel donnant les principales fonctions de readline.

L'idée derrière readline est simple : fournir une librairie permettant simplement d'éditer des lignes de commandes au moment de leur frappe. La gestion des racourcis ctrl+a et ctrl+e, ainsi que l'historique sont des exemples des fonctions supportées par readline.

Revenons à son implémentation ruby, dans sa version la plus simple :

while line = Readline.readline('> ')
  puts "you entered #{line}"
end

Le paramètre pris par la méthode readline défini l'apparence du shell. Quand a la gestion de l'historique, elle est juste triviale : il est accessible via la constante Readline::HISTORY. Son activation demande juste l'ajout d'un boolean à l'appel readline :

while line = Readline.readline('> ', true)
  puts "you entered #{line}"
end

De mon côté, j'avais besoin d'exécuter des commandes simples ne prennant pas d'argument, par exemple: profile create. Il me faut aussi pouvoir définir et modifier certaines variables globale à la session en cours. J'ai défini une classe Setup chargée de contenir et modifier toutes les variables. Quand aux commandes simples, elles ressemblent à des appels de méthodes sur des objets.

La magie du ruby faisant le reste :

require 'readline'
require 'pp'

class Setup
  def initialize
    # set default values
  end
end

class CommandLine
  def initialize
    @setup = Setup.new
    @profile = Profile.new
    @room = Room.new
  end

  def parse(line)
    values = line.split

    case values.first
    when 'setup'
      if values.count == 1
        pp @setup
      elsif values.count == 2
        pp @setup.instance_variable_get("@#{values[1]}")
      elsif values.count == 3
        pp @setup.instance_variable_set("@#{values[1]}", values[2])
      else
        puts "too many arguments"
      end

    else
      var = instance_variable_get("@#{values.shift}")
      if var.nil?
        puts "command not recognized"
      else
        pp var.send(values.shift, *values)
      end

    end
  end

  def loop
    while line = Readline.readline('> ', true)
      next if line.empty?
      parse line
    end
  end
end

CommandLine.new.loop

Très simplement, la classe CommandLine initialise des variables d'instances qui pourront recevoir des commandes sous la forme de simples appels de méthode. La partie setup est quand à elle plus particulière car elle gère 3 cas : l'affichage des variables contenues dans @setup, la consultation d'une des variable ainsi que son édition.

La récupération de la variable d'instance sur laquelle la méthode sera appliquée se fait à l'aide de instance_variable_get nous permettant de récupérer un variable d'instance à partir d'une string. L'exécution de la commande se fait en utilisant send qui permet d'exécuter une méthode à partir d'une string ou d'un symbole.

Après implémentation d'une partie plus spécifique dans les classes Room et Profile, on peut obtenir le résultat suivant :

> setup
#<Setup:0x1003d44c8>
> setup foo
nil
> setup foo 50
"50"
> setup foo
"50"
> setup bar some_value
"some_value"
> setup
#<Setup:0x1003d44c8 @bar="some_value", @foo="50">
> room pouet
"in pouet from room"
> bleh
command not recognized
> setup 1 2 3
too many arguments

Gestion du pasteboard/clipboard

$> echo "something" | pbcopy
$> pbpaste
something

pbcopy permet d'ajouter l'entrée standard au clipboard, ensuite accessible sur toutes les applications.
pbpaste va à l'inverse afficher sur la sortie standard le contenu du clipboard.

Ouverture de documents

$> open test.pdf
$> open http://www.google.com

open offre de nombreuses options permettant d'ouvrir par exemple le document directement dans TextEdit (-e), d'afficher le fichier dans le Finder au lieu de l'ouvrir dans l'application correspondante (-R) ou encore d'ouvrir le fichier dans une application en background pour ne pas perdre le focus dans le terminal.

Synthétiseur vocal

$> say "my computer is beautiful"

say permet de synthétiser le texte passé en paramètre en voix audible sur la sortie audio. Des options permettent de préciser la voix à utiliser, d'éventuellement exporter la sortie dans un fichier au lieu de la sortie son ou encore d'envoyer le son via réseau en utilisant le protocole AUNetSend.

Capture d'écran

$> screencapture file.png

screencapture comme son nom l'indique effectue une saisie d'écran et la sauvegarde dans un fichier. Des options particulièrement utiles permettent d'ouvrir un nouveau mail avec la capture en pièce jointe (-M), de préciser le format (-t), d'ouvrir le fichier dans Preview (-P) ou encore de ne pas jouer de son lors de la capture (-x).

Gestion du système

$> softwareupdate -l
Software Update Tool
Copyright 2002-2009 Apple

No new software available.
$> system_profiler
Hardware:

    Hardware Overview:

      Model Name: MacBook Pro
      Model Identifier: MacBookPro5,3
    .
    .
    .

softwareupdate offre une interface en ligne de commande pour les mises à jour système. Les options permettent de lister les mises à jour disponibles (-l), de lancer leur téléchargement (-d) ou encore leur installation (-i).
system_profiler affiche les informations du système telles que celles affichées dans l'application graphique System Profiler.

Ruby étant totalement objet, derrière les blocks se cache en fait une classe Ruby : Proc. De la déclaration en utilisant les accolades '{}' ou l'ensemble do..end resulte une instance de la classe Proc :

class MyClass
  def envelope(myblock)
    myblock.call
  end
end

m = MyClass.new
p = Proc.new { puts 'test' }
m.envelope p

L'appel yield ainsi que la création de Proc sans pour autant les instancier explicitement sont des éléments de plus à ajouter au sucre syntaxique que nous fourni Ruby. Le code précédent aurait pu être écris :

class MyClass
  def envelope(&myblock)
    myblock.call
  end
end

m = MyClass.new
m.envelope { puts 'test' }

Que vient faire le caractère '&' avant l'argument myblock ? Il convertit simplement l'argument myblock en un objet Proc, en appelant la méthode to_proc. Un exemple que vous avez du voir de nombreuses fois est la conversion d'un symbol en un Proc :

[1,2,3].collect &:to_s
# => ["1", "2", "3"]

Cette fonctionalité présente dans Ruby On Rails depuis de nombreuses releases à été ajoutée à Ruby 1.8.7 et 1.9. Son code simplifié est le suivant :

def to_proc
  Proc.new { |obj| obj.send self }
end

On crée une instance de Proc reçevant l'objet sur lequel on souhaites appeler la méthode (ici, chaque élément de l'array). On appelle la méthode ayant pour nom le symbol (ici, to_s). La méthode collect recoit donc un block prenant un argument et exécutant la méthode correspondant au symbol.

Cependant, cette méthode reste un peu moins efficace que la déclaration explicite d'un block car Ruby devra, au moment de l'exécution, convertir le symbol en Proc. Elle n'en reste pas moins très élégante.

Un autre usage courant des blocks pour clarifier le code est leur utilisation dans des vues ERB Ruby on Rails : les formulaires, conteneurs et même les liens.
Si vous utilisez des balises div avec un traitement spécial (coins arrondis par exemple), une méthode élégante consiste à déclarer un Helper utilisant le block comme contenu de cette div :

<% rounded_block do %>
  Contenu de la div.
<% end %>

L'astuce permettant ici de récupérer le contenu du block pour l'insérer au bon endroit est d'utiliser la méthode capture fournie par Ruby on Rails :

def rounded_block(&block)
  content_tag(:div, :class => "rounded_box") do
    capture &block
  end
end

Les blocks permettant d'écrire plus naturellement des codes complexes, leur utilisation permet d'augmenter à la fois la lisibilité du code et aussi le plaisir d'écriture.

Une des utilisations principales de ces blocks est fait lors de l'itération d'éléments Enumerable :

[1,2,3].each do |item|
  puts item + 5
end

Que se passe -t- il lors de l'exécution du code précédent : le block défini va être passé à la méthode each de l'array. Cette fonction annonyme sera alors exécuté pour chaque élément de l'array, en passant comme paramètre l'élément courant.

Chaque fonction peut recevoir un block et l'exécuter :

class MyClass
  def envelope
    puts "before"
    yield
    puts "after"
  end
end

m = MyClass.new
m.envelope { puts 'test' }

Ce code devrait afficher la chaine de caractères 'test' entre les chaines 'before' et 'after'. La méthode block_given? permet de savoir si un block à été passé à la fonction :

def envelope
  yield if block_given?
end

Une des grandes utilités des blocks est par exemple de pouvoir effectuer un ensemble d'opérations dans le contexte d'une méthode. Cet usage des blocks est particulièrement employé dans les traitements IO (réseau, fichier, ...). En effet, le code contenu dans le block peut exécuter des méthodes de l'instance de classe, si elle est passée en argument du block :

class MyClass
  def envelope(var)
    @given_value = var
    yield self
  end

  def func2
    puts "calling func2, given_value: #{@given_value}"
  end
end

m = MyClass.new
m.envelope("value1") do |my_instance|
  my_instance.func2
end

# => "calling func2, given_value: value1"

On peut aussi passer un block lors de l'instanciation d'une classe, si la méthode initialize adéquate est renseignée, ce qui permet par exemple d'effectuer un certain nombre de traitement sur l'objet dès sa création. Le code obtenu est ainsi plus clair.