Algo::rithmique

RConsole

2010-03-11T00:00:00Z

Cela fait un bout de temps que je devais passer un peu de temps à tester MacRuby¹. C'est chose faite par le biais d'une nouvelle application (et donc d'un nouveau projet) : RConsole.

La genèse

Si vous êtes comme moi, il doit vous arriver, de temps en temps, de faire des scripts Ruby post-it. C'est ce genre de petit script que l'on fait pour tester une chose en particulier et qui finit généralement sous forme de Gist. Pour faire cela, il existe plusieurs solutions. La plus courante étant certainement d'utiliser IRB. Le problème, qu'y en découle, est le fait qu'il est difficile de faire des modifications. Il faut en effet à chaque fois retaper tout le code. Pour peu que celui-ci fasse plusieurs lignes, cela devient rapidement énervant. Une autre solution pour les utilisateurs de TextMate consiste à placer le code dans un fichier et à l'exécuter directement depuis l'éditeur via un ⌘R. Cette dernière solution est plus simple, à condition d'utiliser TextMate et de ne pas avoir peur de se créer un répertoire de scripts que l'on oubliera de nettoyer de temps en temps. Bref, vous l'aurez compris, tout cela ne me plait pas beaucoup.

Comme vous le savez, je suis très flemmard. Et cela ne va pas en s'arrangeant... Et j'ai donc passé une petite soirée à développer une solution qui me va très bien. L'idée est d'avoir une fenêtre contenant un pseudoéditeur de code, code que l'on pourra exécuter et voir le résultat, sans quitter l'application, sans perdre du temps à le sauvegarder on ne sais ou... Tout ceci donne RConsole

Utilisation

Comme vous pouvez le voir sur la capture ci-dessus, RConsole se présente sous forme d'une simple fenêtre permettant de taper un bout de code. Il suffit ensuite de cliquer sur le bouton Run (ou de faire un ⌘R) pour afficher le résultat de la sortie standard et/ou la sortie d'erreur.

Si vous utilisez plusieurs interpréteurs Ruby, vous pouvez les déclarer dans les préférences de l'application.

Vous pouvez alors, via la boite de sélections située en haut à gauche de la fenêtre principale, choisir l'interpréteur à utiliser.

Souvenez-vous qu'il s'agit d'un simple outil de test, inutile donc d'espérer sauvegarder le code dans un fichier en vue d'une réutilisation ultérieure. Si c'est là votre besoin, reprenez votre éditeur favori.

MacRuby

Comme je l'ai dit, ce petit outil a été développé avec MacRuby. Plutôt habitué à utiliser RubyCocoa, je dois bien avouer que j'ai été véritablement bluffé par MacRuby. Il est beaucoup plus proche de Cocoa et donc beaucoup plus agréable à utiliser pour qui aime ce framework. C'est véritablement le mariage idéal entre Ruby et Cocoa !

Seul petit regret, qui s'excuse rapidement, MacRuby ne couvre pas encore totalement l'implémentation de Ruby (1.9). Un exemple : pour l'exécution du code, je souhaitais utiliser Open3². Malheureusement, dans la version 0.6 (nightly build), Open3 n'est pas implémenté, simplement parce qu'il utilise Kernel#spawn qui n'est lui-même pas implémenté... Mon positivisme me poussant à dire que cela me promet de belles évolutions à faire ;)

Je ne devrais pas tarder à publier RConsole sur Github.

Parmi les petites choses que je voudrais y ajouter, il y a la possibilité de poster le code sous forme de Gist. Si de votre côté vous voyez d'autres choses, n'hésitez pas à m'en faire part !

¹ Autrement qu'en faisant un Hello World!
² En doux réveur, j'espérait pouvoir utiliser Open5, mais la encore, MacRuby ne le permet pas.

Mini Taj Mahal Lego

2010-03-07T00:00:00Z

J'ai profité de ce weekend de fin de vacances (pour les enfants) pour me faire un petit Design By Me Lego^©. Voici le plan, étape par étape. Pour ceux qui voudraient se vider le cerveau en passant à la construction, voici le fichier LXF à utiliser avec LEGO Degital Designer. Sachez que vous pouvez commander ce modèle (pour 58,29 €) directement depuis LDD. Pour ma part, je ne manquerai pas de poster une photo du résultat dès que j'aurais reçu la boite ;)

Model Name: Mini Taj Mahal
Number of Bricks: 464

Step 0

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11

Step 12

Step 13

Step 14

Step 15

Step 16

Step 17

Step 18

Step 19

Step 20

Step 21

Step 22

Step 23

Step 24

Step 25

Step 26

Step 27

Step 28

Step 29

Step 30

Step 31

Step 32

Step 33

Step 34

Step 35

Step 36

Step 37

Step 38

Step 39

Step 40

Step 41

Step 42

Step 43

Step 44

Step 45

Step 46

Step 47

Step 48

Step 49

Step 50

Step 51

Step 52

Step 53

Step 54

Step 55

Step 56

Step 57

Step 58

Step 59

Step 60

Step 61

Step 62

Step 63

Step 64

Step 65

Step 66

Step 67

Step 68

Step 69

Step 70

Step 71

Step 72

Step 73

Step 74

Step 75

Step 76

Step 77

Step 78

Step 79

Step 80

Step 81

Step 82

Step 83

Step 84

Step 85

Step 86

Step 87

Step 88

Step 89

Step 90

Step 91

Step 92

Step 93

Step 94

Step 95

Step 96

Step 97

Step 98

Step 99

Step 100

Step 101

Step 102

Step 103

Step 104

Step 105

Step 106

Step 107

Step 108

Step 109

Step 110

Step 111

Step 112

Step 113

Step 114

Step 115

Step 116

Step 117

Step 118

Step 119

Step 120

Step 121

Step 122

Step 123

Step 124

Step 125

Step 126

Step 127

Déployer une application Capcode dans un serveur d'application Java

2010-01-27T00:00:00Z

Depuis la naissance de Capcode, je l'ai pas mal utilisé dans le cadre de mon travail. Je pense que ce petit framework arrive à maturité, ce qui devrait être (j'espère) prouvé avec la sortie de la version 1.0. Jusque-là, outre les inévitables corrections de bugs, je ne prévois pas d'ajouter de nouvelle fonctionnalité majeure pour me concentrer sur les problématiques de déploiement. Ce travail a déjà été initié en validant l'utilisation de Capcode avec Passenger. Je vous propose aujourd'hui de compléter ce chapitre en regardant comment déployer une application Capcode dans un serveur d'application Java.

JRuby-Rack et Warbler

JRuby-Rack est un adaptateur vous permettant d'exécuter une application basée sur Rack dans un container d'application Java. Tout cela sans rien changer au code de votre application. Warbler quant à lui est un gem qui vous permet de créer un fichier war pour votre application Ruby. Le premier est une dépendance du second, et nous nous concentrerons donc sur ce dernier.

Préparer l'application

Afin de vous montrer que la solution Warbler n'impose pratiquement aucun changement dans l'application, je vais partir de l'exemple REST présent dans les sources de Capcode.

Cet exemple est composé de deux fichiers : rest.rb et rest.ru. Le premier est le coeur de l'application. Le second est un fichier de configuration pour rackup. Cela tombe bien, car ce sont justement les deux éléments nécessaires pour utiliser JRuby-Rack.

Dans les exemples qui accompagnent les sources de JRuby-Rack, il semble y avoir une habitude pour l'organisation des sources. Le fichier de configuration de rackup (nommé config.ru) étant placé à la racine, le fichier de l'application est dans un répertoire lib et il existe un répertoire config dans lequel se trouve un fichier warble.rb. Si nous suivons ce modèle, nous devons donc faire trois petits changements :

Réorganiser les fichiers de l'application de façon à obtenir ceci :

rest
|-- README_FIRST
|-- config
|-- rest.ru
`-- lib
    `-- rest.rb

Ayant placé le fichier rest.rb dans le répertoire lib, nous devons légèrement modifier le fichier rest.ru de façon à ce qu'il charge non plus rest mais lib/rest. Nous passons donc de ceci :
```
require 'rest'

run Capcode.application()
```
A cela :
```
require './lib/rest'

run Capcode.application()
```
Enfin, nous renommons le fichier rest.ru en config.ru.

Il nous manque maintenant le fameux fichier warble.rb. Ce fichier peut être généré automatiquement par Warbler. Ce dernier est, en effet, une surcouche de rake :

$ warble -T
rake config             # Generate a configuration file to customize your war assembly
rake pluginize          # Unpack warbler as a plugin in your Rails application
rake version            # Display version of warbler
rake war                # Create rest.war
rake war:app            # Copy all application files into the .war
rake war:clean          # Clean up the .war file and the staging area
rake war:exploded       # Create an exploded war in the app's public directory
rake war:gems           # Unpack all gems into WEB-INF/gems
rake war:jar            # Run the jar command to create the .war
rake war:java_classes   # Copy java classes into the .war
rake war:java_libs      # Copy all java libraries into the .war
rake war:public         # Copy all public HTML files to the root of the .war
rake war:war:java_libs  # Copy all java libraries into the .war
rake war:webxml         # Generate a web.xml file for the webapp
$

Il suffit donc de lancer la commande warble config pour obtenir le fichier config/warble.rb. Cette commande se contente de copier le fichier warble.rb situé dans le répertoire generators/warble/templates/ du gem Warbler dans le répertoire config de notre projet. Regardons donc ce qu'il contient :

 1 # Disable automatic framework detection by uncommenting/setting to false
 2 # Warbler.framework_detection = false
 3 
 4 # Warbler web application assembly configuration file
 5 Warbler::Config.new do |config|
 6   # Temporary directory where the application is staged
 7   # config.staging_dir = "tmp/war"
 8 
 9   # Application directories to be included in the webapp.
10   config.dirs = %w(app config lib log vendor tmp)
11 
12   # Additional files/directories to include, above those in config.dirs
13   # config.includes = FileList["db"]
14 
15   # Additional files/directories to exclude
16   # config.excludes = FileList["lib/tasks/*"]
17 
18   # Additional Java .jar files to include.  Note that if .jar files are placed
19   # in lib (and not otherwise excluded) then they need not be mentioned here.
20   # JRuby and JRuby-Rack are pre-loaded in this list.  Be sure to include your
21   # own versions if you directly set the value
22   # config.java_libs += FileList["lib/java/*.jar"]
23 
24   # Loose Java classes and miscellaneous files to be placed in WEB-INF/classes.
25   # config.java_classes = FileList["target/classes/**.*"]
26 
27   # One or more pathmaps defining how the java classes should be copied into
28   # WEB-INF/classes. The example pathmap below accompanies the java_classes
29   # configuration above. See http://rake.rubyforge.org/classes/String.html#M000017
30   # for details of how to specify a pathmap.
31   # config.pathmaps.java_classes << "%{target/classes/,}p"
32 
33   # Gems to be included. You need to tell Warbler which gems your application needs
34   # so that they can be packaged in the war file.
35   # The Rails gems are included by default unless the vendor/rails directory is present.
36   # config.gems += ["activerecord-jdbcmysql-adapter", "jruby-openssl"]
37   # config.gems << "tzinfo"
38 
39   # Uncomment this if you don't want to package rails gem.
40   # config.gems -= ["rails"]
41 
42   # The most recent versions of gems are used.
43   # You can specify versions of gems by using a hash assignment:
44   # config.gems["rails"] = "2.0.2"
45 
46   # You can also use regexps or Gem::Dependency objects for flexibility or
47   # fine-grained control.
48   # config.gems << /^merb-/
49   # config.gems << Gem::Dependency.new("merb-core", "= 0.9.3")
50 
51   # Include gem dependencies not mentioned specifically
52   config.gem_dependencies = true
53 
54   # Files to be included in the root of the webapp.  Note that files in public
55   # will have the leading 'public/' part of the path stripped during staging.
56   # config.public_html = FileList["public/**/*", "doc/**/*"]
57 
58   # Pathmaps for controlling how public HTML files are copied into the .war
59   # config.pathmaps.public_html = ["%{public/,}p"]
60 
61   # Name of the war file (without the .war) -- defaults to the basename
62   # of RAILS_ROOT
63   # config.war_name = "mywar"
64 
65   # Name of the MANIFEST.MF template for the war file. Defaults to the
66   # MANIFEST.MF normally generated by `jar cf`.
67   # config.manifest_file = "config/MANIFEST.MF"
68 
69   # Value of RAILS_ENV for the webapp -- default as shown below
70   # config.webxml.rails.env = ENV['RAILS_ENV'] || 'production'
71 
72   # Application booter to use, one of :rack, :rails, or :merb. (Default :rails)
73   # config.webxml.booter = :rails
74 
75   # When using the :rack booter, "Rackup" script to use.
76   # The script is evaluated in a Rack::Builder to load the application.
77   # Examples:
78   # config.webxml.rackup = %{require './lib/demo'; run Rack::Adapter::Camping.new(Demo)}
79   # config.webxml.rackup = require 'cgi' && CGI::escapeHTML(File.read("config.ru"))
80 
81   # Control the pool of Rails runtimes. Leaving unspecified means
82   # the pool will grow as needed to service requests. It is recommended
83   # that you fix these values when running a production server!
84   # config.webxml.jruby.min.runtimes = 2
85   # config.webxml.jruby.max.runtimes = 4
86 
87   # JNDI data source name
88   # config.webxml.jndi = 'jdbc/rails'
89 end

Vous me permettrez de faire l'impasse sur le détail complet des paramètres de ce fichier pour me concentrer uniquement sur ceux nécessaires dans le cas d'un déploiement d'application Capcode.

Ce fichier de configuration est prévu pour servir de base dans le cas d'une application Rails. Ainsi à la ligne 10, nous retrouvons la liste des répertoires d'une telle application. Dans notre cas, le seul répertoire utile est lib. Nous remplacerons donc cette ligne par ceci :

config.dirs = %w(lib)

Juste en dessous, nous avons le paramètre include permettant de lister les fichiers devant être ajoutés dans la webapp. Dans notre cas, seul le fichier config.ru est à prendre en compte. Nous ajoutons donc la ligne suivante :

config.includes = FileList["config.ru"]

Les lignes 33 à 49 vous expliquent comment préciser la dépendance de gem pour faire fonctionner notre application. Dans notre exemple, nous en avons besoin de trois : Capcode, capcode-render-markaby et mime-types. La dépendance avec mime-types étant directement héritée de Capcode. Nous ajoutons donc la ligne suivante dans le fichier :

config.gems = ['Capcode', 'capcode-render-markaby', 'mime-types']

Si vous continuez la lecture, vous verrez que le paramètre gem_dependencies est par défaut positionné à true. Ce qui indique que les dépendances de gem non spécifiées seront également prises en compte.

Les lignes 72-73 nous montrent comment indiquer le type de laucher à utiliser. Ce choix se faut entre rack, rails ou merb. Capcode étant basé sur rack, nous positionnerons ce paramètre de la façon suivante :

config.gems = ['Capcode', 'capcode-render-markaby', 'mime-types']

Et voilà. Nous sommes prêts à créer la webapp. Pour cela rien de plus simple :

$ warble
mkdir -p tmp/war/WEB-INF/gems/specifications
cp /Library/Ruby/Gems/1.8/specifications/Capcode-0.9.2.gemspec tmp/war/WEB-INF/gems/specifications/Capcode-0.9.2.gemspec
mkdir -p tmp/war/WEB-INF/gems/gems
cp /Library/Ruby/Gems/1.8/specifications/rack-1.1.0.gemspec tmp/war/WEB-INF/gems/specifications/rack-1.1.0.gemspec
cp /Library/Ruby/Gems/1.8/specifications/mime-types-1.16.gemspec tmp/war/WEB-INF/gems/specifications/mime-types-1.16.gemspec
cp /Library/Ruby/Gems/1.8/specifications/capcode-render-markaby-0.2.0.gemspec tmp/war/WEB-INF/gems/specifications/capcode-render-markaby-0.2.0.gemspec
cp /Library/Ruby/Gems/1.8/specifications/Markaby-0.6.5.gemspec tmp/war/WEB-INF/gems/specifications/Markaby-0.6.5.gemspec
cp /Library/Ruby/Gems/1.8/specifications/builder-2.1.2.gemspec tmp/war/WEB-INF/gems/specifications/builder-2.1.2.gemspec
mkdir -p tmp/war/WEB-INF/lib
cp lib/rest.rb tmp/war/WEB-INF/lib/rest.rb
cp config.ru tmp/war/WEB-INF/config.ru
cp /Library/Ruby/Gems/1.8/gems/warbler-0.9.14/lib/jruby-rack-0.9.5.jar tmp/war/WEB-INF/lib/jruby-rack-0.9.5.jar
cp /Library/Ruby/Gems/1.8/gems/warbler-0.9.14/lib/jruby-rack-0.9.5.jar tmp/war/WEB-INF/lib/jruby-rack-0.9.5.jar
cp /Library/Ruby/Gems/1.8/gems/jruby-jars-1.4.0/lib/jruby-core-1.4.0.jar tmp/war/WEB-INF/lib/jruby-core-1.4.0.jar
cp /Library/Ruby/Gems/1.8/gems/jruby-jars-1.4.0/lib/jruby-core-1.4.0.jar tmp/war/WEB-INF/lib/jruby-core-1.4.0.jar
cp /Library/Ruby/Gems/1.8/gems/jruby-jars-1.4.0/lib/jruby-stdlib-1.4.0.jar tmp/war/WEB-INF/lib/jruby-stdlib-1.4.0.jar
cp /Library/Ruby/Gems/1.8/gems/jruby-jars-1.4.0/lib/jruby-stdlib-1.4.0.jar tmp/war/WEB-INF/lib/jruby-stdlib-1.4.0.jar
mkdir -p tmp/war/WEB-INF
jar cf rest.war  -C tmp/war .
$

Comme vous pouvez le voir, Warbler se charge de créer notre webapp en y plaçant les fichiers de notre application, les gems dont elle dépend, mais également JRuby. Nous avons donc un fichier rest.war totalement portable et donc extrêmement facile à déployer.

Installer et déployer l'application

Dans cet exemple, j'utilise la version 6.0.20 de Tomcat. Je n'ai pas pris le temps de tester avec d'autre serveur Java, mais il n'y a pas de raison pour que cela ne fonctionne pas.

Pour installer l'application, il suffit simplement de copier le fichier rest.war dans le répertoire webapps de Tomcat. Le déploiement se fera de lui-même lors du lancement sur serveur. Pour cela, exécutez le script startup situé dans le répertoire bin de Tomcat. Si vous suivez en parallèle les logs inscrits dans logs/catalina.out, vous devriez, à un moment, voir apparaitre l'information suivante :

INFO: Déploiement de l'archive rest.war de l'application web
JRuby limited openssl loaded. gem install jruby-openssl for full support.
http://jruby.kenai.com/pages/JRuby_Builtin_OpenSSL
...
INFO: Server startup in 32519 ms

C'est parfait... Nous pouvons maintenant utiliser notre application. Pour cela, rendez-vous à l'adresse http://localhost:8080/rest

Si vous poussez le test, vous verrez rapidement que quelque chose ne fonctionne pas :

Rassurez-vous, ceci s'explique très bien. En effet, dans l'application, au niveau des vues, nous utilisons la méthode URL pour générer les valeurs des champs action des formulaires. C'est une bonne pratique, mais qui, dans le cas présent renvoi sur l'url /action alors que, étant dans une webapp, cette route devrait en fait être /rest/action.

Heureusement, tout a été prévu. En effet, la méthode URL est prévue pour fonctionner avec un RACK_BASE_URI spécifique. Dans notre cas, il s'agit de /rest. Il suffit donc de positionner cette valeur avant de démarrer le serveur :

export RACK_BASE_URI=/rest
./bin/startup.sh
open http://localhost:8080/rest

Et cela fonctionne correctement !

Attention !

Lors de la rédaction de ce post, j'ai corrigé quelques bugs dans Capcode. Donc, à moins que la version 0.9.2 (ou supérieure) soit sortie, il faudra récupérer les sources pour tester cela.

Créer son moteur de recherche avec Ruby et Xapian

2009-12-29T00:00:00Z

Il y a quelque mois de cela, j'avais publié dans GNU/Linux Magazine France un article expliquant comment créer son propre moteur de recherche avec Ruby. Je m'étais alors basé sur Ferret, inspiré de Lucene. Aujourd'hui, en lisant Rails Magazine #5, j'ai découvert Xapian.

Xapian est une librairie permettant d'indexer des documents. Elle est écrite en C++ et propose des bindings pour différents langages, dont Ruby. Je vous propose donc de réécrire le moteur de recherche mis en place dans GLMF #107 en utilisant ce moteur.

La méthode utilisée sera exactement la même que celle mise en place dans mon premier article. Nous allons donc créer deux scripts : un crawler/indexer et une interface de recherche. Je ne vous réexpliquerai pas le rôle des différents éléments en vous laissant le soin de refaire un peu de lecture, si besoin. Je vais me concentrer sur le code en mettant en avant les éléments à modifier pour passer de Ferret à Xapian

Installer Xapian

Avant de commencer, nous allons installer Xapian. Ce travail se fera en deux étapes. Tout d'abord, nous devons récupérer, compiler et installer xapian-core :

wget http://oligarchy.co.uk/xapian/1.0.17/xapian-core-1.0.17.tar.gz
tar zxvf xapian-core-1.0.17.tar.gz
cd xapian-core-1.0.17

./configure && make && sudo make install

Il faut maintenant installer le binding pour Ruby. Vous avez plusieurs solutions pour cela. Soit récupérer xapian-bindings, soit (solution que je préfère), récupérer et installer le gem (non officiel) :

git clone http://github.com/xspond/xapian-ruby.git
cd xapian-ruby

gem build xapian-ruby.gemspec
sudo gem install xapian-ruby-0.1.2.gem

Crawler et Indexer

La partie crawler est exactement la même et nous la reprendrons donc telle quelle.

Pour l'indexeur, nous avions vu à l'époque qu'il suffit de créer une instance de Ferret::Index::Index et de lui ajouter les éléments à indexer :

require 'ferret'

# Création de l'index
index = Ferret::Index::Index.new( :path => "index" )

# Ajout du premier document :
index << { :uri => "http://example.com/", :title => "A FooBar example", :content => "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis eget blandit tortor. Vestibulum vitae sem..." }

# Ajout du second document :
index << { :uri => "http://example.com/page.html", :title => "A second FooBar example", :content => "Ut ornare euismod mauris quis molestie. Fusce eget metus sit amet justo pretium ullamcorper sit..." }

# ...

Dans cet exemple, l’option :path permet de préciser le répertoire dans lequel devront être stockés les différents fichiers permettant la persistance de l’index.

Si maintenant nous voulons faire la même chose avec Xapian, voici le code que nous obtenons :

 1 require 'xapian'
 2 
 3 # Création de la base
 4 database = Xapian::WritableDatabase.new("index", Xapian::DB_CREATE_OR_OPEN)
 5 
 6 # Création de l'index
 7 index = Xapian::TermGenerator.new()
 8 index.database = database
 9 index.stemmer = Xapian::Stem.new("french")
10 
11 # Ajout du premier document :
12 document = Xapian::Document.new()
13 document.data = "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis eget blandit tortor. Vestibulum vitae sem..."
14 document.add_term( "Uhttp://example.com/")
15 document.add_term( "TA FooBar example" )
16 index.document = document
17 index.index_text("Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis eget blandit tortor. Vestibulum vitae sem...")
18 database.add_document(document)
19 
20 # Ajout du premier document :
21 document = Xapian::Document.new()
22 document.data = "Ut ornare euismod mauris quis molestie. Fusce eget metus sit amet justo pretium ullamcorper sit..."
23 document.add_term( "Uhttp://example.com/page.html")
24 document.add_term( "TA second FooBar example" )
25 index.document = document
26 index.index_text("Ut ornare euismod mauris quis molestie. Fusce eget metus sit amet justo pretium ullamcorper sit...")
27 database.add_document(document)

Outch ! Xapian est, à première vue, un peu plus lourd que Ferret. La première chose à faire est de créer la base (ligne 4) puis l'indexer (ligne 7) en lui affectant cette base (ligne 8). Vous remarquerez que l'indexer travaille en fonction d'une langue (ligne 9). Ceci fait l'ajout de document se fait en trois étapes :

Tout d'abord, nous créons ce document (ligne 12 à 15).
Nous le passons ensuite à l'indexer (ligne 16) auquel nous demandons d'indexer le contenu (ligne 17).
Pour terminer, nous ajoutons le document dans la base (ligne 18).

A partir de là, je suis certain que vous vous posez plein de questions...

Pourquoi, alors que nous passons le document à l'indexer, fait-il utiliser `index_text` ?

Tout simplement parce que nous ne voulons peut-être pas toujours indexer le contenu complet du document. En effet, dans le cas d'un crawler web par exemple, nous pourrions indexer le document en ne prenant en compte que les mots clés (balise meta, name="keywords"). Dans ce cas, nous ferons plutôt quelque chose comme cela :

 1 # nous partons du principe que nous avons :
 2 #  body     = contenu de la page
 3 #  url      = l'URL de la page
 4 #  title    = le titre de la page
 5 #  keywords = les mots clés récupérés dans la balise meta
 6 
 7 document = Xapian::Document.new()
 8 document.data = body
 9 document.add_term( "U#{url}")
10 document.add_term( "T#{title}" )
11 index.document = document
12 keywords.each do |kw|
13   index.increase_termpos
14   index.index_text(kw)
15 end
16 database.add_document(document)

Notez que nous pouvons pondérer nous même les mots clés. En effet, index_text accepte, en second paramètre, un entier permettant de donner un poids à chacun. Par défaut il est à 1.

Qu'est-ce donc que ces `add_term` ?

Avec Ferret, nous passions notre document sous forme de Hash. Et bien les terms d'un document sont un peu la même chose. Mais afin de les différencier, nous les préfixons (ici U pour l'URL, T pour le titre). Ainsi lors de la recherche nous pourrons récupérer ces informations.

Maintenant que nous savons cela, nous pouvons coder notre crawler/indexer :

  1 require 'digest/md5'
  2 require 'net/http'
  3 require 'uri'
  4 
  5 require 'rubygems'
  6 require 'hpricot'
  7 require 'xapian'
  8 
  9 DEBUG = true
 10 
 11 class HTTPDocument
 12   attr_reader :highlevel, :pages
 13   
 14   def initialize( )
 15     @level = 0
 16     @highlevel = 0
 17     @pages = []
 18      
 19     @database = Xapian::WritableDatabase.new("index", Xapian::DB_CREATE_OR_OPEN)
 20 
 21     @indexer = Xapian::TermGenerator.new()
 22     @indexer.database = @database
 23     @indexer.stemmer = Xapian::Stem.new("french")
 24   end
 25   
 26   def indexer( uri, title, content, digest )
 27     puts "[INDEX] - Index #{uri}..."
 28     @highlevel = @level if @highlevel < @level
 29     @pages << uri
 30     
 31     document = Xapian::Document.new()
 32     document.data = content
 33     document.add_term( "U#{uri}")
 34     document.add_term( "T#{title}" )
 35     document.add_term( "M#{digest}" )
 36 
 37     @indexer.document = document
 38     @indexer.index_text(content)
 39 
 40     @database.add_document(document)
 41   end
 42   
 43   def crawler( uri )    
 44     puts "[CRAWL] - Level ##{@level} : #{uri}..."
 45 
 46     # Récupération de la ressource
 47     url = URI.parse( uri )
 48     
 49     # Récupération du contenu
 50     response = Net::HTTP.get_response( url )
 51     
 52     # En cas d'erreur, nous ignorons la page
 53     if response.class != Net::HTTPOK
 54       puts "\t[ERROR] - #{uri} : Bad URL!" if DEBUG
 55     end
 56 
 57     # Récupération du contenu de la page
 58     pageContent = response.body
 59 
 60     # Calcul du MD5 de la page
 61     pageDigest = Digest::MD5.hexdigest( pageContent )
 62     
 63     # Si la page a déjà été indexé nous l'ignorons
 64     if @database.term_exists( "M#{pageDigest}" )
 65       puts "\t[IGNORE] - #{uri} : Already parsed!" if DEBUG
 66       return
 67     end
 68     
 69     # Indexation
 70     case response.content_type 
 71       when "text/html"
 72         pageDocument = Hpricot( pageContent )
 73         pageTitle = (pageDocument/"title")[0]
 74         pageTitle = ((pageTitle.nil?)?"":pageTitle.inner_html) # "
 75         
 76         indexer( uri, pageTitle, pageContent, pageDigest )
 77         
 78         # Parcour des liens
 79         (pageDocument/"a").each do |element|
 80           href = element['href']
 81           begin
 82             __href = URI.parse( href )
 83             if __href.scheme.nil?
 84               __href.scheme = url.scheme
 85               __href.host = url.host
 86               __href.port = url.port
 87               __href.path = __href.path.gsub( "./", "/" ).gsub( "//", "/" )
 88               href = __href.to_s
 89             end
 90         
 91             if url.host == URI.parse( href ).host
 92               href += "/" if URI.parse( href ).path == ""
 93               unless @database.term_exists( "U#{href}" )
 94                 @level = @level + 1
 95                 crawler( href ) 
 96                 @level = @level - 1
 97               end
 98             else
 99               puts "\t[IGNORE] - #{href} : Host not match!" if DEBUG
100             end
101           rescue => e
102             puts "\t[ERROR] - Error at #{href} : #{e.message}" if DEBUG
103           end            
104         end
105       when "text/plain"
106         pageDocument = pageContent
107         pageTitle = uri
108         
109         indexer( uri, pageTitle, pageContent, pageDigest )
110       else
111         puts "\t[IGNORE] - #{uri} : Not Text or HTML!" if DEBUG
112     end
113   end
114 end
115 
116 site = HTTPDocument.new( )
117 
118 b = Time.now
119 site.crawler( ARGV[0] )
120 e = Time.now
121 
122 puts "#{site.pages.size} indexed :"
123 site.pages.each do |p|
124   puts "\t- #{p}"
125 end
126 puts "High level : #{site.highlevel}"
127 puts "Time : #{e - b}s"

L’interface de recherche

Avec Ferret voici ce que j'avais mis en place la dernière fois :

index = Index::Index.new(:path => './index')
index.search_each('content:"' + search_term + '"') do |id, score|
  out.write( "<p>" )
  out.write( "<a href='#{index[id][:url]}'>#{index[id][:title]}</a> <small>- [score of #{score}]</small><br />" )
  highlights = index.highlight('content:"' + search_term + '"', 0,
                                   :field => :content,
                                   :pre_tag => "<b>",
                                   :post_tag => "</b>")
  out.write( "<small>#{highlights}</small>" )
  out.write( "<small><a href='#{index[id][:url]}'>#{index[id][:url]}</a></small>")
  out.write( "</p>\n" )
end

Et voici comment nous faisons la même chose avec Xapian :

 1 database = Xapian::Database.new("index")
 2 
 3 enquire = Xapian::Enquire.new(database)
 4 
 5 qp = Xapian::QueryParser.new()
 6 qp.stemmer = Xapian::Stem.new("french")
 7 qp.database = database
 8 qp.stemming_strategy = Xapian::QueryParser::STEM_SOME
 9 
10 enquire.query = qp.parse_query(search_term)
11 
12 # On ne prend que les 10 premiers résultats.
13 matchset = enquire.mset(0, 10)
14 
15 matchset.matches.each do |m|
16   url = ''
17   title = ''
18     
19   m.document.terms.each do |t|
20     title = t.term.gsub(/^T/, "") if /^T/.match(t.term)
21     url = t.term.gsub(/^U/, "") if /^U/.match(t.term)
22   end
23   out.write( "<p>" )
24   out.write( "<font size='+1'><a href='#{url}'>#{title}</a></font> <small>- [score of #{m.percent}%]</small><br />" )
25   out.write( "<small><a href='#{url}'><font color='green'>#{url}</font></a></small>")
26   out.write( "</p>" )
27 end

Outch !¹ Là encore, le code est beaucoup plus long avec Xapian. Il y a seulement deux petites choses importantes à voir ici :

ligne 8, nous définissons la statégie de recherche de termes en fixant la valeur de Xapian::QueryParser#stemming_strategy à Xapian::QueryParser::STEM_SOME. Cela veut tout simplement dire que nous ne prenons pas en compte les termes commençant par une majuscule, donc pas notre U<url> ou notre T<titre>. Ce qui est plutôt une bonne chose.
Pour récupérer l'URL et le titre justement, nous parcourons les termes rattachés à chaque document trouvé et nous extrayions celui préfixé, respectivement, par U et T (ligne 19 à 22).

Bien entendu, je me suis limité à la plus courte explication. Mais si vous regardez la documentation de Xapian, vous verrez que vous pouvez aller beaucoup plus loin, en gérant en particulier la correction orthographique ou la synonymie...

En attendant, voici le code complet de notre interface de recherche :

 1 #!/usr/bin/env ruby
 2 
 3 require 'rubygems'
 4 require 'mongrel'
 5 require 'xapian'
 6 
 7 class ResultHandler < Mongrel::HttpHandler
 8   def process( request, response )
 9     response.start(200) do |head, out|
10       head["Content-Type"] = "text/html"
11       
12       search_term = begin
13         Mongrel::HttpRequest.query_parse( request.params['QUERY_STRING'] )['s']
14       rescue
15         nil
16       end
17       out.write( "<html>
18 <head>
19   <meta http-equiv=content-type content='text/html; charset=UTF-8'>
20   <title>Mooteur</title>
21   <link rel='stylesheet' href='/style.css' type='text/css' media='screen' />
22 </head>
23 <body>
24   <div id='left'>
25     <table><tr>
26       <td><a href='/'><img src='/mooteur.gif' alt='Mooteur...' width='200' border='0'></a></td>
27       <td><form action='/r'>
28         <input type='text' name='s' size='41' value='#{search_term}' />
29         <input type='submit' value='Recherche Mooteur'/>
30       </form></td>
31     </tr></table>
32   </div>")
33   
34   if search_term
35   
36     database = Xapian::Database.new("index")
37     enquire = Xapian::Enquire.new(database)
38     qp = Xapian::QueryParser.new()
39     stemmer = Xapian::Stem.new("french")
40     qp.stemmer = stemmer
41     qp.database = database
42     qp.stemming_strategy = Xapian::QueryParser::STEM_SOME
43     query = qp.parse_query(search_term)
44     # Find the top 10 results for the query.
45     enquire.query = query
46     matchset = enquire.mset(0, 10)
47 
48     out.write( "  <div id='results'>
49   <div id='head'>
50     #{matchset.matches_estimated()} r&eacute;sultats pour <b>#{search_term}</b>
51   </div>
52     
53     <div id='list'>")
54     
55     matchset.matches.each do |m|
56       url = ''
57       title = ''
58         
59       m.document.terms.each do |t|
60         title = t.term.gsub(/^T/, "") if /^T/.match(t.term)
61         url = t.term.gsub(/^U/, "") if /^U/.match(t.term)
62       end
63       out.write( "<p>" )
64       out.write( "<font size='+1'><a href='#{url}'>#{title}</a></font> <small>- [score of #{m.percent}%]</small><br />" )
65       out.write( "<small><a href='#{url}'><font color='green'>#{url}</font></a></small>")
66       out.write( "</p>" )
67     end
68 
69     out.write( "    </div>
70   </div>
71 </body>
72 </html>" )
73     end
74     end
75   end
76 end
77 
78 h = Mongrel::HttpServer.new( "0.0.0.0", "3000" )
79 h.register( "/", Mongrel::DirHandler.new("./static/") )
80 h.register( "/r", ResultHandler.new )
81 h.run.join

Conclusion

Je terminerai, encore une fois, en vous précisant qu'il existe de très intéressants plugins Xapian pour Rails dont acts_as_xapian et xapit (à utiliser avec xapit-sync).

¹ again !

SoapUI-3.5-beta1.app

2009-12-28T00:00:00Z

Bien que cela fasse déjà plusieurs jours qu'Ediware a mis en ligne la première beta de SoapUI 3.5, je viens seulement de prendre le temps de créer le .app pour MacOSX. Ce délai est principalement dû au fait que j'ai eu besoin de retravailler un peu le script utilisé pour créer ce .app. Quoi qu'il en soit, le DMG est disponible. J'ai encore quelques modifications à apporter pour parfaire la génération. Mais s'agissant d'une beta de la part d'Ediware, mon build s'en tiendra au même statut. Ceci me laisse un peu de temps jusqu'à la sortie de la version finale ;)

Notez que comme toujours il ne s'agit ici que de la version Open Source. Pour la version pro ou la version packagée par Ediware, je vous laisse voir ici.

Ruby Timer

2009-12-24T00:00:00Z

J'ai profité du calme de cette période festive pour travailler sur mes projets. Le nombre de contributeurs sur Ruby/GraphViz augmentant, j'ai nous avons sorti une nouvelle version. Idem pour Capcode¹ qui est passé en version 0.8.9. Mais le projet sur lequel j'ai passé le plus de temps est certainement RComet².

- Mais pourquoi, sachant que tout cela devrait être rapidement déprécié par les WebSockets ?

Anyway !

Tout cela pour en arriver au fait que j'ai eu besoin de gérer le timeout des connexion dans RComet afin de détecter la déconnexion d'un client qui n'aurait pas eu la politesse de prévenir. Et pour cela je me suis amusé à développer une petite classe permettant de gérer un timer avec Ruby. Je vous la livre ici, mais sachez qu'il existe également un Gist

 1 require 'rubygems'
 2 require 'eventmachine'
 3  
 4 class Timer
 5   def initialize
 6     @run = false
 7     @timeout_proc = nil
 8   end
 9   
10   # Run <tt>blk</tt> every <tt>every</tt> seconds during <tt>during</tt> seconds 
11   def self.start( every = 1, during = 5, &blk )
12     t = Timer.new()
13     t.start( every, during, &blk )
14   end
15   
16   # Run <tt>blk</tt> every <tt>every</tt> seconds during <tt>during</tt> seconds 
17   def start( every = 1, during = 5, &blk )
18     @run = true
19     Thread.new do
20       time = Time.now
21       EventMachine.run do 
22         reschedule = proc { |inc, block| 
23           if Time.now - time > during
24             self.stop
25             @timeout_proc.call unless @timeout_proc.nil?
26           else
27             @timer = EM.add_timer(inc) { reschedule.call(inc, block) }
28             block.call 
29           end
30         }
31         @timer = EM.add_timer(every) { reschedule.call(every, blk) }
32         blk.call
33       end
34     end
35     return self
36   end
37   
38   # Timeout !
39   def timeout( &blk )
40     @timeout_proc = blk
41     return self
42   end
43   
44   # Stop the timer
45   def stop
46     EM.stop_event_loop if @run
47     @run = false
48     return self
49   end
50 end
51  
52 ## Example
53 if $0 == __FILE__
54   t = Timer.start(5, 20) { 
55     puts "Please, give me your name..."
56   }.timeout {
57     puts "Too late rabbit !!!"
58     exit 0
59   }
60  
61   r = $stdin.readline
62   puts "Hello #{r}"
63   
64   t.stop
65 end

¹ Il n'y a pas autant de contibuteurs :(
² Guillaume, si tu m'entend...

Bye bye TextMate, Bonjour Coda

2009-12-21T00:00:00Z

Comme vous avez pu le constater, je suis en pleine période de changement. Cela a commencé avec ce site¹. Mais j'ai profité de cette mutation pour abandonner TextMate au profit de Coda.

Coda est un éditeur de code qui se dit orienté Web, mais il n'en reste pas moins tout à fait utilisable pour le reste. C'est cependant assez difficile de changer ses habitudes. Heureusement, Coda arrive avec un éditeur de plugins extrêmement simple à utiliser, qui m'a permis de démarrer le développement d'un plugin regroupant plusieurs petites choses que j'appréciais particulièrement dans TextMate. La première concerne l'exécution du code depuis l'éditeur (le fameux ⌘R). Je n'ai pas encore de solution satisfaisante pour cette action, mais cela prend forme. Idem pour l'intégration de Git qui commence à ressembler à quelque chose ;)

Du côté de la coloration syntaxique, Coda est assez pauvre. Bonne nouvelle, il utilise le format Mode de SubEthaEdit. Il est donc possible de récupérer tout le travail déjà réalisé pour ce dernier, mais également de créer ce qui nous manque. Ce n'est d'ailleurs pas la seule chose que Coda reprend de SubEthaEdit, puisqu'il intègre Subetha Engine . J'ai eu l'occasion de le tester sur un petit développement et je dois avouer que si cela peut sembler un peu gadget, cela s'avère extrêmement intéressant.

Pour terminer sur Coda, j'étais un grand utilisateur d'Open In Textmate. Et bien, pour ne pas rompre avec cette bonne habitude, je me suis amusé à développer Open In Coda :

¹ et il semble que ce sujet ne soit pas totalement clos.

Bye bye Wordpress, Bonjour Jekyll

2009-12-18T00:00:00Z

Cela faisait longtemps que je voulais quitter le doux monde de Wordpress pour passer sur un nouveau système de blog plus proche de mes aspirations. Après ce n'est qu'une question de temps et de bonne volonté... Et bien c'est fait puisque ce site est maintenant propulsé par Jekyll.

Il existe pas mal de choix dans les outils de blog. Toute la question consiste à trouver celui qui est le plus en adéquations avec vos besoins, votre philosophie... Mon choix pour Jekyll s'explique par plusieurs raisons, dont principalement le fait qu'il s'agit en fait d'un générateur de site statique, à partir de templates. Cette solution présente de multiples avantages dont un véritablement différenciant : la possibilité de faire des modifications sans obligatoirement avoir accès à internet. C'est par exemple le cas de ce post que je rédige en ce moment même dans une salle d'attente. Je peux non seulement le rédiger, mais également voir comment tout s'articule. Avec un outil comme Wordpress, bien entendu vous pouvez faire la rédaction "hors ligne", mais impossible de vérifier le rendu. A moins bien entendu d'avoir un Worpress installé localement.

Dans la version Wordpress de ce site, j'utilisais pas mal de plug-ins. Une des premières questions que je me suis posées avant de faire un choix définitif était de savoir comment conserver la coloration syntaxique du code. En bon utilisateur de Github, j'ai bien entendu pensé à cette solution. Ce qui me dérangeait le plus était le fait que le code embarqué dans un article est alors obligatoirement détaché de ce dernier. Lors de ma recherche, j'ai vu que Jekyll propose de la coloration syntaxique via Pygments \o/

Côté plugins, j'utilisais également StatPress. Cela se remplace très bien par un Google Analytics ;)

Enfin, il y avait WP-reCAPTCHA pour éviter le spam dans les commentaires. Eh oui, un blog ne serait pas un blog sans commentaires. Pour cette partie, j'utilise Disqus. Non seulement il permet d'ajouter les commentaires, mais en plus de les gérer.

Donc, bienvenu à vous sur cette nouvelle version d'algo::rithmique. Il n'est pas impossible que lors de la phase de migration je sois passé à côté de certaines petites choses (images ou liens cassés, ...) n'hésitez pas à m'en faire part.

Au fait, n'oubliez pas de changer l'URL du fil RSS si vous lisez ce blog à travers un lecteur de news.

Server side Faye’s client ou le protocole Bayeux

2009-11-24T00:00:00Z

Dans mon précédent article, je vous ai montré comment mettre en place un Comet avec Capcode. J'ai découvert que certains d'entre vous lisent ce que j'écris¹ par le biais de quelques mails dans ma boite aux lettres. L'un d'entre vous m'a même demandé comment faire pour envoyer des évènements sur le bus Comet sans passer par l'application Web. Bonne question, sachant qu'en effet, faye ne propose aucune solution pour cela. Et bien je me suis amusé à en développer une...

Faye

Pour comprendre ce que nous allons faire, il faut prendre le temps de regarder comment fonctionne faye. Mais avant, nous devons choisir la solution à adopter pour écrire notre librairie. En effet, nous avons deux choix possibles : soit nous pouvons parler directement au serveur faye, soit nous pouvons simuler le comportement d'un client. En fonction de ce choix, nous regarderons telle ou telle partie du code de faye. Bon et puisque c'est moi qui choisis², j'opte pour la seconde solution.

Avant de décortiquer le code, rappelons le cheminement par l'utilisateur lors de l'utilisation de soapbox. Avant tout nous démarrons l'application³. Nous donnons notre username. Ensuite nous indiquons qui nous voulons suivre. Enfin nous racontons notre vie. Ces deux dernières étapes pouvant se faire dans n'importe quel ordre, et autant de fois que nous voulons.

Regardons maintenant le code. Lors de l'accès à l'application (route /) nous recevons la page mise en place par la vue views/index.rhtml. Dans cette vue, ce qui nous intéresse ce sont les lignes suivantes :

1 <script type="text/javascript">
2   Comet = new Faye.Client('/comet');
3   Comet.connect();
4     
5   Soapbox.init(Comet);
6 </script>

Nous créons un client Comet (ligne 41) pour le bus accessible via la route /comet puis nous établissons la connexion (ligne 42). Ensuite nous initialisons l'application (ligne 44). Si nous regardons à quoi correspondent la création et la connexion du client Comet, il faut se plonger dans le code du script comet.js. Ce fichier est généré lors de la création du gem faye à partir de l'ensemble des fichiers contenus dans le répertoire client des sources. Le fichier qui nous intéresse principalement ici est client/client.js. Dans ce fichier vous trouverez le code correspondant à la connexion entre les lignes 75 et 113.

Si nous regardons maintenant le fichier soapbox.js nous pouvons étudier ce qui se passe lors de l'initialisation de l'application. Nous voyons dans ce code que soapbox attend que l'utilisateur saisisse son username. Une fois ceci fait, l'application souscrit au channel /mentioning/<username>, elle masque la zone de saisie du username et affiche les zones de saisie des personnes à suivre et des messages. Elle met ensuite en place les actions correspondantes pour ces deux zones de saisie. La première de ces actions se traduit par la souscription au channel /from/<follow> avec comme callback : accept. La seconde revoie vers la méthode post dont le rôle principal est de publier le message sur le channel /from/<username>.

Outch !

Ce qui est important ici c'est de voir ce dont nous avons besoin pour faire cela. Nous en retiendrons donc la nécessité de développer une méthode de connexion, une méthode de souscription et une méthode de publication. Pour comprendre comment ces méthodes agissent, il suffit de regarder ce qui est fait dans les méthodes correspondantes de Faye.Client.

Je ne vais pas pouvoir, au risque de perdre plus de monde que ceux qui ont déjà lâché prise avant la fin du dernier paragraphe, entrer plus dans les détails. Il va donc falloir me croire sur parole ;) En fait, ce que nous allons faire c'est mettre en place une version cliente du protocole des échanges Comet appelé protocole Bayeux. Je vous engage donc à en lire la documentation si vous souhaitez approfondir le sujet.

Messages

Les échanges entre le client Comet et le bus peuvent se faire de deux façons, soit en long-polling soit en callback-polling. Dans notre cas, nous utilisons la première solution en faisant un envoie en POST du paramètre message, ce dernier ayant pour valeur une chaine JSON.

Mettons cela en place :

module Faye
  class Client
    def initialize( uri_or_string )
      @uri = uri_or_string
      @uri = URI.parse(@uri) if @uri.class == String

      # ...

    end

    # ...

    private
    def send( message )
      res = Net::HTTP.post_form( @uri, { "message" => message.to_json } )
      return JSON.parse( res.body )
    end
  end
end

Je place cette méthode en private car elle n'a d'intérêt que pour les méthodes que nous allons écrire ensuite.

Comme vous pouvez le voir, le retour est également une structure JSON.

"Handshake"

Si vous regardez précisément ce qui se passe lors de l'initialisation de la connexion du client Comet, vous verrez qu'en fait, il n'y a pas de connexion véritable, mais un handshake. Cela consiste en fait à se présenter au bus Comet et à obtenir de sa part, un identifiant. Nous devrons, par la suite toujours, utiliser cet identifiant pour communiquer avec le bus.

Le message du handshake doit contenir au moins les champs suivants :

channel : le channel.
version : la version du protocole.
supportedConnectionTypes : les types de connexions supportées.

Un channel est représenté comme un chemin sous la forme /foo/bar/... et doit systématiquement commencer par un /. Il en existe deux types : ceux définis par l'application et ceux réservés par le protocole. Ces derniers commencent toujours par /meta/. Dans le cas du handshake, le channel doit être /meta/handshake.

La version doit correspondre au numéro de version du protocole. 1.0 ici.

Le paramètre supportedConnectionTypes contient la liste des types de transports supportés. Bien que nous ayons dit plus haut que nous emploierons du long-polling, nous positionnerons la valeur ["long-polling", "callback-polling"]. Ceci simplement parce que si nous souhaitons implémenter le callback-polling nous n'aurons pas de modification à faire ;)

Voici donc à quoi ressemblera la méthode de handshake :

module Faye
  class Client
    def initialize( uri_or_string )
      @uri = uri_or_string
      @uri = URI.parse(@uri) if @uri.class == String
      @clientId = nil
      @interval = nil

      # ...

    end

    # ...

    def handshake
      id = Faye.random(32)
      message = {
        "channel" => Faye::Channel::HANDSHAKE,
        "version" => Faye::BAYEUX_VERSION,
        "supportedConnectionTypes" => [ "long-polling", "callback-polling" ],
        "id" => id
      }
      
      response = send( message )[0]
      if response["successful"] and response["id"] == id
        @clientId = response["clientId"]
        @interval = response["advice"]["interval"]
      else
        raise
      end
    end

    # ...

  end
end

Dans cette méthode j'utilise Faye::Channel::HANDSHAKE et Faye::BAYEUX_VERSION, deux constantes déclarées dans faye. Si vous souhaitez être indépendant de ce dernier, vous pouvez remplacer ces valeurs par celle que j'ai indiquée. Vous noterez également que j'ai ajouté dans le message le paramètre optionnel id. Ce paramètre permettra de valider, dans certains cas, que la réponse que nous recevons est bien celle attendu. En effet, si en retour nous retrouvons ce même ID c'est que, à priori tout va bien. Je dis bien "à priori"...

Je vous ai indiqué que la raison d'être de ce handshake était de récupérer un identifiant client. C'est ce que nous faisons en parsant la réponse. Cette réponse peut avoir deux structures différentes en fonctions ou non de la présence d'erreur. Je ne détaillerai pas la structure complète, retenez seulement quand dans le cas présent nous devons avoir récupéré les données suivantes :

successful : suffisament parlant je pense ;)
id : qui doit correspondre à l'ID envoyé.
clientId : le clientId a utiliser par la suite.

Je ne parlerai pas de la valeur interval que je récupère simplement en pensant à une prochaine évolution de ce petit développement...

Connexion

La connexion se fait en envoyant un message contenant les données suivantes :

channel : dans le cas d'une connexion nous utiliserons /meta/connect qui sera ici récupéré via la constante Faye::Channel::CONNECT.
clientId : est la valeur récupérée lors du handshake
connectionType : je n'y reviens pas, mais vous l'avez compris, nous faisons du long-polling.
id : là encore, ce n'est que mimétisme.

Voici donc comment nous pouvons implémenter cela :

module Faye
  class Client
    def initialize( uri_or_string )
      @uri = uri_or_string
      @uri = URI.parse(@uri) if @uri.class == String
      @clientId = nil
      @interval = nil

      # ...

    end

    # ...

    def connect
      id = Faye.random(32)
      message = {
        "channel" => Faye::Channel::CONNECT,
        "clientId" => @clientId,
        "connectionType" => "long-polling",
        "id" => id
      }
      r = send( message )
            
      # ...

    end
  end
end

A ce niveau, si vous faites un petit test, vous vous rendrez compte que la connexion attend une réponse de la part du serveur. En effet cette connexion attend que le bus Comet envoie des données. C'est ainsi que nous simulons le push ! Ce sont ces données que nous devrons donc traiter en fonction des souscriptions.

Pour savoir si le retour est exact, nous devons retrouver dans la structure JSON le champ successful à true et le champ id avec la même valeur que celle envoyée.

Si tout se passe bien, alors nous pouvons récupérer les données du message dans la structure data :

module Faye
  class Client
    def initialize( uri_or_string )
      @uri = uri_or_string
      @uri = URI.parse(@uri) if @uri.class == String
      @clientId = nil
      @interval = nil

      # ...

    end

    # ...

    def connect
      id = Faye.random(32)
      message = {
        "channel" => Faye::Channel::CONNECT,
        "clientId" => @clientId,
        "connectionType" => "long-polling",
        "id" => id
      }
      r = send( message )
            
      if r[0]["id"] == id and r[0]["successful"] == true

        # traitement du message contenu dans r[1]["data"] pour la souscription au channel r[1]["channel"]
        # ...

      elsif r[0]["successful"] == false

        # ...

      end
      
      # ...

    end

    # ...

  end
end

Nous verrons au paragraphe souscription comment traiter le message de réponse. Avant cela, détaillons ce que nous devons faire en cas d'échec. Le protocole Bayeux nous indique que dans un tel cas, il faut refaire un handshake puis refaire la connexion. Cependant, comme la connexion elle-même est bloquante, dans le sens où elle attend une réponse, il serait bon de l'isoler dans un thread afin de permettre le déroulement de notre programme. De plus, si la connexion est un succès, une fois le message traité, il faut en rouvrir une de façon à se remettre en attente d'un nouveau push du serveur. Pour cela nous pouvons placer la connexion dans une boucle infinie.

Voici donc comment nous allons gérer cela :

module Faye
  class Client
    def initialize( uri_or_string )
      @uri = uri_or_string
      @uri = URI.parse(@uri) if @uri.class == String
      @clientId = nil
      @interval = nil
      @connection = nil

      # ...

    end

    # ...

    def connect
      @connection.kill unless @connection.nil?
      @connection = Thread.new {
        faild = false
        while true
          id = Faye.random(32)
          message = {
            "channel" => Faye::Channel::CONNECT,
            "clientId" => @clientId,
            "connectionType" => "long-polling",
            "id" => id
          }
          r = send( message )
            
          if r[0]["id"] == id and r[0]["successful"] == true

            # traitement du message contenu dans r[1]["data"] pour la souscription au channel r[1]["channel"]
            # ...

          elsif r[0]["successful"] == false
            faild = true
            break
          end
        end
        
        if faild
          handshake()
          connect()
        end
      }
    end

    # ...

  end
end

Souscription

La souscription se fait pour un ou plusieurs channels avec, en second paramètre, la méthode qui doit être utilisée pour traiter les massages venant de ces channels. Nous avons déjà parlé des channels. Bien entendu dans le cas présent il s'agira de channels spécifiques à l'application. Concernant le callback, nous utiliserons un block.

Le message envoyé au bus Comet doit contenir les informations suivantes :

channel : il ne s'agit pas, ici, du channel auquel nous souhaitons souscrire, mais celui utilisé par le protocole pour déclarer une souscription : /meta/subscribe, ou, dans notre cas ou nous utilisons faye : Faye::Channel::SUBSCRIBE.
clientId : le client ID récupéré lors du handshake.
subscription : ce paramètre prend en valeur un tableau des channels auxquels nous souhaitons souscrire.
id : l'id du message.

Comme vous pouvez le voir, nulle part nous ne stockons le callback à utiliser pour traiter les messages renvoyés. C'est normal puisque le bus Comet n'en à que faire puisqu'il seront exécutés côté client. Il nous appartient donc de les stocker. Nous ferons cela en mettant en place un hashage ayant pour clé le channel et comme valeur le block.

module Faye
  class Client    
    def initialize( uri_or_string )
      @uri = uri_or_string
      @uri = URI.parse(@uri) if @uri.class == String
      @clientId = nil
      @interval = nil
      @connection = nil
      @subscriptions = {}
    end

    # ...

    def subscribe( channels, &block )
      channels = [channels] unless channels.class == Array
      if block
        channels.each do |c|
          @subscriptions[c] = block
        end
      end
      message = {
        "channel" => Faye::Channel::SUBSCRIBE,
        "clientId" => @clientId,
        "subscription" => channels,
        "id" => Faye.random(32)
      }
      
      r = send(message)
    end

    # ...

  end
end

Je ne prends pas la peine de gérer le retour. Ce n'est pas bien !

Connexion

Nous pouvons maintenant revenir sur la connexion afin de traiter les messages. Il suffit donc de passer le message au block correspond au channel qui l'a poussé :

    # ...

    def connect
      @connection.kill unless @connection.nil?
      @connection = Thread.new {
        faild = false
        while true
          id = Faye.random(32)
          message = {
            "channel" => Faye::Channel::CONNECT,
            "clientId" => @clientId,
            "connectionType" => "long-polling",
            "id" => id
          }
          r = send( message )
            
          if r[0]["id"] == id and r[0]["successful"] == true
            @subscriptions[r[1]["channel"]].call( r[1]["data"])
          elsif r[0]["successful"] == false
            faild = true
            break
          end
        end
        
        if faild
          handshake()
          connect()
        end
      }
    end

    # ...

Publication

La publication se fait par l'envoi d'un message contenant les champs suivants :

channel : le channel destinataire du message.
data : les données, sous forme d'une structure JSON.
clientId : le fameux client ID.
id : par habitude ;)

Ceci nous donne donc le code suivant :

module Faye
  class Client

    # ...

    def publish( channel, data )
      message = [
        {
          "channel" => channel,
          "data" => data, 
          "clientId" => @clientId,
          "id" => Faye.random(32)
        }
      ]
      r = send(message)[0]
    end

    # ...

  end
end

Encore une fois, je ne prends pas le temps de traiter la réponse... Encore une fois, ce n'est pas bien !!!

... et leur contraire

Là où il y a connexion, il y a forcement "déconnexion", de même la où il y a souscription, il y a désabonnement. Je pense que vous avez compris le principe, et je me permets donc de vous livrer sans autre explication les méthodes correspondantes :

module Faye
  class Client

    # ...

    def disconnect
      unless @connection.nil?
        @connection.kill 
        message = {
          "channel" => Faye::Channel::DISCONNECT,
          "clientId" => @clientId,
          "id" => Faye.random(32)
        }
        r = send( message )
      end
    end

    # ...

    def unsubscribe( channels )
      channels = [channels] unless channels.class == Array
      channels.each do |c|
        @subscriptions.delete(c)
      end
      message = {
        "channel" => Faye::Channel::UNSUBSCRIBE,
        "clientId" => @clientId,
        "subscription" => channels,
        "id" => Faye.random(32)
      }
      
      r = send(message)
    end

    # ...

  end
end

Let's play !

Maintenant que nous avons notre librairie cliente, nous pouvons développer un petit client en ligne de commande pour soapbox.

x = Faye::Client.new( 'http://localhost:3000/comet' )

puts "-- handshake"
x.handshake

puts "-- subscriptions"
x.subscribe( "/mentioning/daemon" )

x.subscribe( "/from/greg" ) { |r|
  puts "#{r["user"]} : #{r["message"]}"
}

puts "-- connect"
x.connect

msg = ""  
while msg != "quit"
  msg = $stdin.readline.chomp
  unless msg == "quit"
    channel = "/from/daemon"
    data = { "user" => "daemon", "message" => msg }
    r = x.publish( channel, data )
    unless r["successful"]
      puts "=> Message not send !"
    end
  end
end

x.disconnect

Bon, OK, c'est très très rudimentaire, mais vous avez compris ! Et le principal c'est que cela fonctionne :

A+

Attention, n'oubliez pas la remarque faite sur la page du projet faye : it's a toy. Donc, tout comme ce qui précède, n'utilisez pas cela en production⁴. Et bien cela s'applique, à plus forte raison, à ce qui est écrit ci-dessus. Maintenant, si vous êtes joueur, vous pouvez récupérer cela dans les sources de Capcode ou ici.

Notez que si je me suis attaché à faye, ce petit client devrait pouvoir fonctionner avec toute solution Comet respectant le protocole Bayeux.

¹ Merci !
² :P
³ Ca peut paraitre idiot, cela n'en reste pas moins vrai !
⁴ On vous aura prévenu !

Notification, Comet, ... Capcode

2009-11-21T00:00:00Z

Depuis que nous développons des sites Web, nous avons pris l'habitude du mode connecté imposé par le protocole HTTP. Rien ne nous surprend plus quand nos serveurs ne répondent qu'à des demandes explicites. Et nous vivons avec l'habitude de ce dialogue de sourds ou le serveur répond à une requête en oubliant totalement ce qu'il a dit à la demande précédente. Nous pallions généralement à ce problème en utilisant des principes de session et autre cookie, mais n'oublions pas que ces artefacts sont en fait gérés par le client à qui le serveur demande de stocker des souvenirs. Depuis l'apparition des frameworks JavaScript comme Dojo, prototype, jQuery et consorts, nous mettons de plus en plus de mécanismes dans les pages Web qui évitent de reloader toute une page. Là encore, cela ne fait plus rêver personne et nous restons toujours dans un mode requête/réponse. Là où nous écarquillons un peu plus les yeux, c'est quand une page Web affiche, sans que nous n'ayons rien demandé, de nouvelles informations. C'est tout le principe des notifications et c'est ce que nous allons mettre en place ici.

Notifications ?

Une notification intervient quand un serveur envoie des données au client quand il en a envie, et donc sans aucune demande du client. En dehors du Web, tous les systèmes de messagerie instantanés, par exemple, fonctionnent sur ce principe. Mais de par son côté stateful, le protocole HTTP ne permet pas ce genre de chose. Faux ! me direz-vous. La preuve par Google, ou plutôt Google Mail qui non seulement ne nous oblige pas à reloader sa page pour découvrir de nouveaux messages, mais qui en plus propose un service de messagerie instantanée aussi efficace que n'importe quel Skype ou MSN ! Et bien malheureusement, c'est vrai. Et si nous arrivons à faire de la notification via le Web ce n'est que par le truchement de bidouillages plus ou moins subtils qui vont permettre de le simuler. Depuis plusieurs années, nous désignons les mécanismes permettant de faire du push HTTP sous le terme Comet, inventé par Alex Russell.

Comet

Comet est une désignation peu claire. En effet, personne ne sait très bien ce que recouvre ce terme. Globalement on lui attribut tous les mécanismes permettant de faire de la notification.

Oui mais comment faire cela justement ?

Dans son fonctionnement classique, un serveur HTTP attend une requête du client et renvoie une réponse :

Avec AJAX, nous avons rajouté, côté client, une couche entre l'utilisateur et le serveur. C'est elle qui reçoit les demandes du client, qui les transmet au serveur, qui reçoit la réponse, et elle se charge de mettre à jour la page. Ceci fait que les chargements sur la page ne sont pas forcement synchronisés avec les échanges qui ont lieu entre le moteur AJAX et le serveur :

Cela permet ainsi de mettre à jour des informations dans la page sans tout recharger. Avec AJAX, nous pouvons déjà simuler un comportement de notifications. En effet, il suffit de demander au moteur AJAX d'envoyer une requête, à intervalle régulier au serveur, et si ce dernier à une nouvelle information, de l'afficher. Mais ce n'est pas du Comet. En effet, dans ce cas, ce n'est pas le serveur qui est à l'initiative de l'envoi de données. De plus, l'envoi de données par le serveur est rythmé par les demandes du client. Et même si elles peuvent être très rapprochées, elles ne donneront pas toujours le même sentiment de fluidité que nous retrouverons avec un Comet bien fait.

Avec Comet, nous allons remplacer le serveur AJAX pas un client Comet qui se placera entre le client et le serveur. Côté serveur, nous allons placer un bus Comet chargé de communiquer avec le service :

Côté client, la connexion Comet est initialisée. A partir de là, le service enverra des évènements au bus Comet qui se chargera d'envoyer les informations nécessaires au client Comet qui à son tour mettra à jour la page Web. Bien entendu le client peut lui même envoyer de l'information au service par l'intermédiaire du client puis du bus Comet. Vous l'aurez compris, nous utilisons aussi de l'AJAX. Quant au service, cela peut être n'importe quoi : un service de messagerie instantané, un serveur de données, ... bref n'importe quel service capable lui-même de pousser des données.

Capcode

Avec Capcode nous pouvons faire du Comet en utilisant un middleware Rack. Personnellement j'en ai trouvé 2 : Pusher et faye. Bien qu'un peu moins aboutit que le premier, je vous propose d'utiliser faye.

faye arrive avec un exemple sous forme de messagerie instantanée à la Twitter. Pour valider le fonctionnement de faye avec Capcode, je vous propose d'adapter cet exemple.

soapbox est écrit comme une application Sinatra. Le code de l'application est minimaliste :

require 'rubygems'
require 'sinatra'

get '/' do
  @server = env['faye.server']
  erb :index
end

La seule chose remarquable ici est le fait que lors de l'accès à la racine de l'application, le serveur et modifié pour devenir le serveur faye et que nous renvoyons la page index.erb. Transformer cela en code Capcode est ultra simple :

 1 require 'rubygems'
 2 require 'capcode'
 3 require 'capcode/render/erb'
 4 
 5 module Capcode
 6   set :erb, "views"
 7 
 8   class Index < Route '/'
 9     def get
10       @server = env['faye.server']
11       render :erb => :index
12     end
13   end
14 end

Pour respecter ce qui est fait, nous créons un répertoire views dans lequel nous placerons les templates Erb, tout cela sans oublié de le déclarer (ligne 6).

Si nous regardons maintenant le fichier de configuration pour Rack, nous avons cela :

dir = File.dirname(__FILE__)

require dir + '/../../lib/faye'
require dir + '/app'

use Faye::RackAdapter, :mount => '/comet'
run Sinatra::Application

Ajouter cela dans Capcode est là encore trivial :

require 'rubygems'
require 'capcode'
require 'capcode/render/erb'
require 'faye'

module Capcode
  set :erb, "views"
  use Faye::RackAdapter, :mount => '/comet'
  
  class Index < Route '/'
    def get
      @server = env['faye.server']
      render :erb => :index
    end
  end  
end

Si maintenant nous regardons le template Erb nous voyons qu'il utilise une CSS et trois fichiers JavaScript :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 
<html>
<head>
  <meta http-equiv="Content-type" content="text/html
 charset=utf-8" />
  <title>Faye demo: chat client</title>
  <link rel="stylesheet" href="/style.css" type="text/css" media="screen">
  <script src="/jquery.js" type="text/javascript"></script>
  <script src="/comet.js" type="text/javascript"></script>
  <script src="/soapbox.js" type="text/javascript"></script>
</head>
<body>
<div class="container">
...

Les fichiers style.css, jquery.js et soapbox.js se trouvent dans le répertoire public. Nous devons donc créer ce même répertoire et déclarer son existence dans Capcode :

require 'rubygems'
require 'capcode'
require 'capcode/render/erb'
require 'faye'

module Capcode
  set :erb, "views"
  set :static, "public"
  use Faye::RackAdapter, :mount => '/comet'
  
  class Index < Route '/'
    def get
      @server = env['faye.server']
      render :erb => :index
    end
  end  
end

Puis nous modifions le template Erb :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>
<head>
  <meta http-equiv="Content-type" content="text/html
 charset=utf-8" />
  <title>Faye demo: chat client</title>
  <link rel="stylesheet" href="/public/style.css" type="text/css" media="screen">
  <script src="/public/jquery.js" type="text/javascript"></script>
  <script src="/comet.js" type="text/javascript"></script>
  <script src="/public/soapbox.js" type="text/javascript"></script>
</head>
<body>
<div class="container">
...

Oui, mais le fichier comet.js ??? Et bien si vous regardez la documentation de faye, vous verrez que le simple fait de déclarer l'utilisation du middleware faye met automatiquement en place un bus Comet accessible via la route /comet et met à disposition la librairie JavaScript cliente via la route /comet.js. Donc, nous n'avons rien de plus à faire pour ce fichier.

Vous pouvez maintenant démarrer l'application et tester :

Cet exemple a été ajouté dans les sources de Capcode.

Toute l'intelligence de l'exemple se trouve non seulement fans faye mais également dans le fichier soapbox.js que je vous engage vivement à regarder, tout comme la documentation de faye.

Sequel sans... séquelle ;)

2009-11-12T00:00:00Z

Il y a quelques jours, je vous proposais une solution pour utiliser ActiveRecord sans Rails. Comme je vous l'avais indiqué, cette idée n'avait pour seul but que de permettre une utilisation d'Active Record dans Capcode. C'est maintenant au tour de Sequel...

Contrairement à ActiveRecord, Sequel n'a pas été développé pour un framework. Ce n'est pas non plus (initialement) un ORM, mais une librairie d'accès pour des bases de données, un peu comme DBI. Cependant, contrairement à ce dernier, il se rapproche de DataMapper ou ActiveRecord par sont côté SQL dissimulé. Bref, Sequel se situe entre DBI et ActiveRecord/DataMapper.

Voici un petit exemple :

require "rubygems"
require "sequel"

# Connection à une base SQLite 
DB = Sequel.connect( "sqlite://test.db" )

# Création d'une table 
DB.create_table :users do
  primary_key :id
  String :login
  String :password
end

# Ajout de données dans la table
DB[:users].insert( :login => 'Muriel', :password => 'leiruM' )
DB[:users].insert( :login => 'Greg', :password => 'gerG' )

# Affichage du contenu de la table 
DB[:users].all.each do |record|
  puts "#{record[:login]} : #{record[:password]}"
end

J'ai dit un peu plus haut que Sequel n'était pas un ORM. Ce n'est pas tout à fait vrai. En effet, il offre la possibilité d'être utilisé comme tel :

require "rubygems"
require "sequel"

# Connection à une base SQLite 
DB = Sequel.connect( "sqlite://test.db" )

# Création d'une table 
DB.create_table :users do
  primary_key :id
  String :login
  String :password
end

# Mapping
class User < Sequel::Model
end

# Ajout de données dans la table
User.insert( :login => 'Muriel', :password => 'leiruM' )
User.insert( :login => 'Greg', :password => 'gerG' )

# Affichage du contenu de la table 
User.all.each do |record|
  puts "#{record.login} : #{record.password}"
end

Bon, mais quel est l'objectif recherché me demanderez-vous ? Et bien simplement de palier à certains petits défauts de conception qui me dérange dans Sequel.

Déclaration des modèles

Il est impossible dans Sequel de déclarer un modèle si la table correspondante n'existe pas, ou, tout au moins, si la connexion à la base n'a pas été faite avant cette déclaration. Ainsi, faire ceci provoque une erreur :

# Mapping
class User < Sequel::Model
end

# Connection à une base SQLite 
DB = Sequel.connect( "sqlite://test.db" )

DB.create_table :users do
  primary_key :id
  String :login
  String :password
end

# => Sequel::Error: No database associated with Sequel::Model

Si par contre nous faisons la connexion avant, cela semble fonctionner :

# Connection à une base SQLite 
DB = Sequel.connect( "sqlite://test.db" )

# Mapping
class User < Sequel::Model #:users
end

DB.create_table :users do
  primary_key :id
  String :login
  String :password
end

Je dis bien semble, car en fait le comportement de la classe User n'est pas le même si la table existe avant la déclaration du modèle. Ainsi, si vous faites ceci :

# Connection à une base SQLite 
DB = Sequel.connect( "sqlite://test.db" )

DB.create_table :users do
  primary_key :id
  String :login
  String :password
end

# Mapping
class User < Sequel::Model
end

Vous pourrez utiliser la classe User en considérant les champs de la table users comme des accesseurs de cette classe :

User.all.each do |user|
  puts user.login
  puts user.password
end

Si par contre vous créez la table après avoir déclaré le modèle, votre classe User n'a plus le même comportement et vous devez passer par la méthode values de la classe User qui renvoie un hashage des données :

# Connection à une base SQLite 
DB = Sequel.connect( "sqlite://test.db" )

# Mapping
class User < Sequel::Model #:users
end

DB.create_table :users do
  primary_key :id
  String :login
  String :password
end

# ...

# Affichage du contenu de la table 
User.all.each do |record|
  puts record.values[:login]
  puts record.values[:password]
end

Tout cela n'est pas très rigoureux et pas réellement exploitable.

Création de table et migration

Pour la création des tables, là encore j'ai un problème. En effet, comme vous avez pu le constater, la méthode create_table est une méthode d'instance de Sequel::Database récupérée via une connexion (Sequel.connect). Ceci implique que nous ne pouvons proposer un schéma de table qu'après avoir initialisé la connexion à la base. Si cela semble tout à fait logique, cela peut entrainer pas mal de contraintes dans certains cas. Oui, mais pas avec Capcode ! Effectivement, les méthodes Capcode.run et Capcode.application prenant en paramètre un bloc, il est possible de créer les tables dans ce bloc. Cependant, cela rompt avec la philosophie souhaitée pour l'utilisation de ce bloc¹ qui veut que l'on réserve ce bloc pour y placer des éléments de configuration de l'application (remplissage de table, ...) et non pas du code pour l'application.

Si vous avez l'habitude d'utiliser ActiveRecord ou DataMapper ce type de problème ne vous aura jamais dérangé parce que dans le premier cas vous utilisez les migrations, et donc vous générez le schéma à priori, et dans le second, le schéma fait partie intégrante du modèle et il est donc créé automatiquement².

Heureusement³ Sequel offre la possibilité d'utiliser des migrations. Pour cela, vous avez plusieurs solutions. Soit définir vos migrations dans des fichiers et utiliser l'option -m de l'outil sequel, soit utiliser la méthode apply de Sequel::Migration. Grâce à cette dernière possibilité, nous pouvons résoudre le problème évoqué en décrivant le schéma dans une migration et en faisant la migration juste après la connexion :

require "rubygems"
require "sequel"

# Chargement de l'extension permettant les migrations
Sequel.extension :migration

# Migration
class CreateUser < Sequel::Migration
  def up
    create_table :users do
      primary_key :id
      String :login
      String :password
    end
  end
  
  def down
    drop_table :users
  end
end

# Connection à une base SQLite 
DB = Sequel.connect( "sqlite://test.db" )

# Mise en place du schéma
CreateUser.apply( DB, :up )

So what ?

Avec tout ce que nous venons de voir, nous sommes en mesure de mettre en place une classe mimant ce que nous avons fait avec ActiveRecord mais pour Sequel. Donc nous pouvons repartir d'un exemple similaire⁴ :

require 'rubygems'
require 'sq'

# Mise en place des migrations (versionnées)
class CreateUsers < SQ::Schema 1.0
  def up
    create_table :users do
      String :login
      String :password
    end
  end
 
  def down 
    drop_table :users
  end
end

class CreatePosts < SQ::Schema 1.1
  def up
    create_table :posts do
      String :title
      String :body
    end
  end
 
  def down 
    drop_table :posts
  end
end

# Création des modèles
class User < SQ::Model
end

# Connexion
SQ.db_connect( "test.yml", "test.log" )

# Utilisation
User.insert(:login => 'Muriel', :password => 'leiruM')
User.insert(:login => 'Greg', :password => 'gerG')

User.each do |d|
  puts u[:login]
end

La mise en place des schémas est quasiment identique à ce que nous avons fait avec ActiveRecord et nous allons encore une fois déclarer une méthode de classe qui renverra une classe qui sera, dans le cas présent, de type Sequel::Migration. Par la suite, dans la méthode de connexion (SQ.db_connect), nous suivrons exactement le même procédé que celui imaginé pour ActiveRecord, en s'adaptant juste au comportement de Sequel :

module SQ
  class << self
    def Schema( n )
      @final = [n, @final.to_f].max
      m = (@migrations ||= [])
      Class.new(Sequel::Migration) do
        meta_def(:version) { n }
        meta_def(:inherited) { |k| m << k }
      end
    end
  
    def db_connect( dbfile, logfile )
      dbconfig = YAML::load(File.open(dbfile)).keys_to_sym
      dbconfig[:adapter] = "sqlite" if dbconfig[:adapter] == "sqlite3"
      version = dbconfig.delete(:schema_version) { |_| @final }
      
      db = Sequel.connect(@cnx)
      
      if @migrations
        db.create_table? :schema_table do
          Float :version
        end
        si = db[:schema_table].first || (db[:schema_table].insert(:version => 0)
 {:version => 0})
        @migrations.each do |k|
          k.apply(db, :up) if si[:version] < k.version and k.version <= version
          k.apply(db, :down) if si[:version] >= k.version and k.version > version
        end
        db[:schema_table].where(:version => si[:version]).update(:version => version)
      end
    end
  end
end

Nous allons cependant devoir faire quelques adaptations mineures dans ce code pour régler le cas des modèles. Il n'est en effet pas possible d'utiliser les modèles proposés par Sequel, mais ceci ne nous empêche pas de les mimer. Pour cela nous allons créer de toutes pièces la classe SQ::Model et nous ferons en sorte qu'elle réponde, via ses méthodes de classe, aux mêmes méthodes que Sequel::Dataset. Par example la classe User répondra aux même méthodes que DB[:users]. Or :users == User.to_s.tableize.to_sym, ce qui rende la mise en place de la classe SQ::Model extrêmement simple :

module SQ
  class Model
    def self.method_missing( name, *args, &block )
      if block_given?
        SQ::db[self.to_s.tableize.to_sym].__send__(name.to_sym, *args, &block)
      else
        SQ::db[self.to_s.tableize.to_sym].__send__(name.to_sym, *args)
      end
    end
  end
end

Le seul élément vraiment remarquable dans ce code est l'utilisation de SQ::db sensé représenter la connexion. Et c'est là que nous devons modifier le code de la partie schéma pour permettre de partager la connexion au sein du module SQ. Pour cela nous mettons en place la méthode suivante :

module SQ
  class << self
    def db
      @db ||= Sequel.connect(@dbconfig)
    end
  end
end

Puis nous supprimons la ligne db = Sequel.connect(@cnx) dans SQ::db_connect, nous remplaçons partout l'utilisation de la variable db par SQ::db et nous modifions la variable dbconfig en la passant en variable d'instance. Finalement, le code complet est le suivant :

 1 begin
 2   require 'sequel'
 3   Sequel.extension :migration
 4   Sequel.extension :inflector
 5 rescue LoadError => e
 6   raise LoadError, "Sequel ne doit pas être installé : #{e.message}"
 7 end
 8 
 9 class Object
10   def meta_def(m,&b)
11     (class<<self
12 self end).send(:define_method,m,&b)
13   end
14 end
15 
16 class Hash
17   def keys_to_sym
18     self.each do |k, v|
19       self.delete(k)
20       self[k.to_s.to_sym] = v
21     end
22   end
23 end
24 
25 module SQ
26   class Model
27     def self.method_missing( name, *args, &block )
28       if block_given?
29         SQ::db[self.to_s.tableize.to_sym].__send__(name.to_sym, *args, &block)
30       else
31         SQ::db[self.to_s.tableize.to_sym].__send__(name.to_sym, *args)
32       end
33     end
34   end
35   
36   class << self
37     def db
38       @db ||= Sequel.connect(@dbconfig)
39     end
40 
41     def Schema( n )
42       @final = [n, @final.to_f].max
43       m = (@migrations ||= [])
44       Class.new(Sequel::Migration) do
45         meta_def(:version) { n }
46         meta_def(:inherited) { |k| m << k }
47       end
48     end
49 
50     def db_connect( dbfile, logfile )
51       @dbconfig = YAML::load(File.open(dbfile)).keys_to_sym
52       @dbconfig[:adapter] = "sqlite" if @dbconfig[:adapter] == "sqlite3"
53       version = dbconfig.delete(:schema_version) { |_| @final }
54       
55       if @migrations
56         SQ::db.create_table? :schema_table do
57           Float :version
58         end
59         si = SQ::db[:schema_table].first || (SQ::db[:schema_table].insert(:version => 0)
60  {:version => 0})
61         @migrations.each do |k|
62           k.apply(SQ::db, :up) if si[:version] < k.version and k.version <= version
63           k.apply(SQ::db, :down) if si[:version] >= k.version and k.version > version
64         end
65         SQ::db[:schema_table].where(:version => si[:version]).update(:version => version)
66       end
67     end
68   end
69 end

Notez que nous utilisons l'extension inflector afin de pouvoir utiliser la méthode String.tableize et que nous prenons en compte (ligne 51) le fait que Sequel permet d'utiliser SQLite en nommant sont adaptateur sqlite là ou les autres utilisent sqlite3.

Voilà, tout ceci a été mis en place dans Capcode et un petit example illustre comment l'utiliser.

¹ Laquelle ?
² Tout ceci est extrêmement schématique, je sais, mais je ne m'étendrais pas plus sur le sujet.
³ Faudrait savoir ! Un coup on aime, un coup on aime pas les migrations !
⁴ Pour des questions de bonne compréhension, nous placerons notre code dans le module SQ là ou nous utilisions AR...

Happy happymapper

2009-11-09T00:00:00Z

Si vous suivez ce blog, vous savez que je travaille¹ depuis plusieurs mois sur un outil permettant de montrer la puissance des APIs développées dans la boite dans laquelle je travaille. L'outil en question, outre sont côté fonctionnel spécifique, présente la particularité de fonctionner avec l'ensemble des bases de données médicamenteuses proposées par VIDAL. J'entends par là le fait que les données étant diffusées à l'international, il existe, non seulement une version Française, mais également une version pour les Emirats Arabes Unis, pour l'Espagne, le Portugal, ... Et alors ?

Et alors, ce besoin a des impacts non négligeables sur le développement de certaines fonctions. Je ne vais pas entrer dans les détails de la sécurisation d'une prescription, mais juste vous dire que pour la prise en compte de l'état pathologique d'un patient, nous codons cet état via la CIM. Or l'utilisation de cette classification, et plus fortement sa diffusion, est soumise à une licence payante pour chaque pays. Or VIDAL n'ayant acquis qu'une licence pour la France, les versions internationales de la base n'intègrent pas les libellés de la CIM. Tout mon problème était de savoir comment permettre de travailler avec ces libellés quand la démo se fait à l'international ? Plus précisément, comment faire en sorte qu'une personne ayant acquis la licence puisse utiliser mon outil avec sa CIM.

Initialement, j'avais opté pour une solution consistant à déporter la classification dans une base SQLite ne contenant qu'une seule table avec trois colonnes :

Par défaut cette base ne contenait que les codes CIM sans les libellés. Il suffisait, localement, de remplacer le fichier SQLite pour pouvoir accéder aux libellés.

Tout cela était sans compter sur le fait que les personnes qui ont besoin de cet outil ont souvent une approche technique proche de l'état larvaire, et que leur demander de créer un fichier SQLite, aussi simple soit-il, tient du roman de science-fiction chez certains². J'ai donc dû chercher du côté des outils plus classiques de cette population chez qui Excel est un prolongement synaptique. J'ai alors découvert que ce merveilleux outil est capable de générer des fichiers XML. Sauvé³ !

Maintenant que nous savons que nous pouvons utiliser du XML, un simple fichier formaté comme ce qui suit suffit :

<cims>
  <cim10>
    <code>A00.-</code>
    <parent></parent>
    <label>Cholera</label>
  </cim10>
  <cim10>
    <code>A00.0</code>
    <parent>A00.-</parent>
    <label>Choléra classique</label>
  </cim10>

  ...
</cims>

Parcourir un fichier XML est une chose relativement facile avec Ruby. Il existe un grand nombre de modules pour nous y aider. Dans le cas présent, j'ai choisis HappyMapper. Ce dernier permet mapper du XML dans des objets. Ainsi, avec le fichier XML des codes CIM, il suffit de créer l'objet suivant :

class Cim10
  include HappyMapper
  
  element :code, String
  element :parent, String
  element :label, String
end

Si ensuite nous parsons le contenu du fichier XML (via Cim10.parser nous obtenons un tableau d'objets Cim10 :

cims = Cim10.parse(File.read("cim10-fr.xml"))

Tout le problème maintenant c'est de pouvoir faire des recherches dans ce tableau. Pour cela je me suis amusé à transformer le tableau de sortie en utilisant une nouvelle classe : HappyArray :

require "rubygems"
require "active_record/dynamic_finder_match"

class HappyArray < Array
  def find( h )
    r = HappyArray.new
    self.each do |cim|
      keep = true
      h.each do |k, v|
        term = v
        term = v.join('|') if v.class == Array
        keep = keep && !(cim.send(k).downcase.match(term.downcase).nil?)
      end
      r << cim if keep
    end
    return r
  end
  
  def method_missing(method_name, *args, &block)
    if match = ActiveRecord::DynamicFinderMatch.match( method_name )
      finder = {}
      match.attribute_names.each do |f|
        finder[f.to_sym] = args.shift
      end
      return find( finder )
    end
    return HappyMapper.new
  end
end

Cette classe me permet ainsi de faire ceci :

cims = Cim10.parse(File.read("cim10-fr.xml"))
happyCims = HappyArray.new(cims)

results = happyCims.find( :label => "choléra" )
# => Tableau des objets Cim10 dont le libellé contient le terme "choléra"

results = happyCims.find_by_label_and_code( ["choléra", "vaccin"], "A00" )
# => Tableau des objets Cim10 dont le libellé contient "choléra" ou "vaccin" et dont le code contient "A00"

Je n'ai pas voulu ajouter les méthodes de la classe HappyArray à la classe Array car finalement elles ne peuvent servir que dans le cas d'une utilisation avec HappyMapper. La question maintenant c'est de savoir si je sécurise un peu ce code et le propose comme patch pour HappyMapper ou pas ?

¹ Vous pouvez aussi regarder ceci ;)
² Suivez mon regard...
³ Enfin presque... Le problème, maintenant, va être d'expliquer comment faire :(

Algo::rithmique

RConsole

La genèse

Utilisation

MacRuby

Mini Taj Mahal Lego

Déployer une application Capcode dans un serveur d'application Java

JRuby-Rack et Warbler

Préparer l'application

Installer et déployer l'application

Attention !

Créer son moteur de recherche avec Ruby et Xapian

Installer Xapian

Crawler et Indexer

Pourquoi, alors que nous passons le document à l'indexer, fait-il utiliser index_text ?

Qu'est-ce donc que ces add_term ?

L’interface de recherche

Conclusion

SoapUI-3.5-beta1.app

Ruby Timer

Bye bye TextMate, Bonjour Coda

Bye bye Wordpress, Bonjour Jekyll

Server side Faye’s client ou le protocole Bayeux

Faye

Messages

"Handshake"

Connexion

Souscription

Connexion

Publication

... et leur contraire

Let's play !

A+

Notification, Comet, ... Capcode

Notifications ?

Comet

Capcode

Sequel sans... séquelle ;)

Déclaration des modèles

Création de table et migration

So what ?

Happy happymapper

Pourquoi, alors que nous passons le document à l'indexer, fait-il utiliser `index_text` ?

Qu'est-ce donc que ces `add_term` ?