Dev blog af83 | This is the developers blog @ af83

Ruby tricks: Array syntax

2012-05-02T00:00:00+02:00

How many times have you seen those ruby code examples?

if my_array.present?
  my_array
else
  []
end

# Or the ternary version:
my_array.present? ? my_array : []

# Or even the 'or' version:
my_array || []

In those examples, a presence check is made on my_array, otherwise, it will return an empty list. It's valid ruby code, but there's a simpler way to achieve that:

# Just:
Array(my_array)

With nil or an empty array, Array will return an empty array, and with an array of values, it will return the same array of values.

It can also be used if you don't know if you have only one item or an array. This syntax removes useless verifications, and always returns an array.

Another nice trick is about each and map (and theirs aliases).

# Calling save on all items in this collection
collections.each do |item|
  item.save
end

The same result can be achieved this way :

# Calling save on all items in this collection
collections.each &:save

Quelques conseils pour tenir bon lors d'une soirée électorale

2012-04-23T00:00:00+02:00

Comme vous le savez, hier s'est tenue la soirée électorale pour le premier tour des élections présidentielles française. À cette occasion, j'étais dans les locaux de France Télévisions avec l'équipe de rédaction dédiée à l'information sur Internet. En effet, af83 a développé la plateforme de résultats pour France Télévisions et j'étais là pour parer à toute éventualité.

Je profite donc de cette expérience pour vous donner quelques conseils pour gérer ce genre de situations.

1. La préparation

Il est important d'arriver bien préparé parce que vous pouvez être sûr qu'il va y avoir des problèmes. Pas forcément des bugs graves, mais on va vous remonter des problèmes. Je vous conseille donc de prendre un peu de temps pour réfléchir aux problèmes qui pourraient vous arriver et prévoir un plan de secours pour chacun.

L'exemple typique est que le serveur web n'arrive plus à traiter les requêtes assez vite. Pour cela, la réponse est tout aussi classique : utiliser un cache devant le serveur web (Varnish, Akamai, etc.) et pouvoir facilement enclencher un code rouge, un mode dégradé qui va mettre tous les fichiers principaux en cache avec un TTL très long. Le site va donc être bien moins dynamique mais au moins, il s'affichera, vous laissant ainsi un peu de temps pour trouver une meilleure solution.

Cette préparation doit aussi se matérialiser sous la forme d'une documentation sur l'administration et l'exploitation de l'application. On y trouvera, par exemple, comment relancer les différents services et les conséquences associées (est-ce que cela va entrainer un downtime ?).

Cette documentation va sûrement vous donner des séquences de commandes qui vont bien ensemble : aller dans tel répertoire, lancer telle commande pour regénerer tel fichier puis flusher Varnish. Dans ces cas là, il est souvent intéressant de se préparer un moyen pour lancer la séquence en une commande (script ruby, alias ou fonction shell, etc.). Ça vous fera gagner un peu de temps, mais surtout ça vous évitera d'oublier une étape dans la séquence ou de la faire dans le mauvais ordre…

2. L'action

La préparation est importante, mais même en étant très bien préparé, on n'est pas à l'abri d'une mauvaise surprise. À ce moment là, il est important de garder la tête froide. Il est très tentant de vouloir corriger le plus vite possible le problème, quitte à coder directement sur les serveurs de production. Et pourtant ce n'est pas une bonne idée : vous risquez d'aggraver la situation.

Une fausse commande est très vite arrivée. Des exemples ? Oublier le WHERE d'une commande SQL ? Vous avez modifié le mot de passe de tous les utilisateurs. Une variable mal initialisée ? Vous venez d'écraser un fichier très important. Remonter l'historique du shell et prendre la mauvaise commande ? Vous êtes bon pour refaire cet import de données qui prend 3h. Bref, si vous cédez à la panique, vous aurez à peu près autant de chances d'améliorer le service que l'empirer.

Il convient donc de garder son calme, de respirer un grand coup et de tester sur un autre environnement les modifications que vous allez faire. Puis, quand vous serez connecté sur les serveurs de production, prenez deux secondes avant d'appuyer sur Entrée. Ce n'est pas parce que des gens courent dans tous les sens les bras levés que vous devez faire n'importe quoi. Là, plus que jamais, il convient de prendre un peu de recul.

Essayez aussi de vous protéger. Par exemple, si vous allez modifier un fichier, faites une copie du fichier avant. Si vous lancez un script qui va régénerer une page HTML, appelez d'abord l'URL de cette page pour qu'elle soit dans le cache, ce qui vous laissera un peu de temps pour vérifier le fichier généré avant qu'il ne soit en ligne. Et s'il n'est pas bon, vous avez fait une copie, non ? Si vous devez refaire un import, est-ce que vous pouvez le faire sur un autre serveur et juste importer un dump SQL ou un tarball des fichiers mis à jour ? Bref, limitez ce qui pourrait mal se passer.

Dernière chose, soyez concentré. À partir du moment où vous commencez à avoir une demande, vous allez très rapidement en avoir d'autres. Et vous allez donc essayer de les traiter en même temps. Ce script va au moins prendre 30 secondes, j'ai le temps d'aller jeter un coup d'oeil au code source pour cet autre bug : c'est une très mauvaise idée. Faire du multi-tâches est le meilleur moyen pour faire des erreurs.

TL;DR

Pour résumer, soyez bien préparé, ne cédez pas à la panique, gardez la tête froide, vérifiez plutôt deux fois qu'une tout ce que vous faites sur le serveur et ne faites qu'une seule chose à la fois. Ces conseils ne sont que des conseils, pas une méthode magique pour éviter tout problème. Mais ils devraient vous aider à réduire fortement les ennuis.

Gem money

2012-04-11T00:00:00+02:00

Money est une gem qui sert à gérer les devises en Ruby. Elle est utilisée notamment par shopify pour activemerchant.

Elle permet de faire des comparaisons de devises, de créer des objets Money simplement et de les convertir avec des taux soit saisis manuellement, soit avec une autre gem qui le fait pour vous.

Par défaut, elle ne gère pas les taux de conversion, mais la page du projet liste plusieurs gems que vous pourrez utilisez pour ça. Je vais vous parler de money-open-exchange-rates.

L'avantage de cette dernière, c'est qu'elle utilise le JSON mis à jour toute les heures par le currencybot.

La gem reprend pratiquement la même base de code que eu_central_bank mais en utilisant le JSON du projet open-exchange-rates.

Nous avons donc, grâce à open-exchange-rates, accès aux taux de plus de 158 devises au lieu des 32 de la gem eu_central_bank.

Écrire un service web en C

2012-04-11T00:00:00+02:00

Récemment Bruno expliquait comment utiliser Go pour écrire des services web. Go est un langage puissant, conçu autant pour les performances, que pour faciliter la vie des développeurs. Je vous conseille de relire ses deux premiers articles sur le sujet, le premier vous donnera les bases, et le second vous donnera envie d'en savoir plus.

Néanmoins, en y repensant, je me suis demandé à quoi pourrait ressembler un service web équivalent écrit en C. Faire du web en C est une idée saugrenue et dangereuse dans (presque) tous les cas. Enfin, si le langage lui même est moins amical que Go, il a derrière lui les années de développeurs barbus, et il lui reste encore de beaux jours… :)

Il y a mille manières de faire du web en C. Pour aller au plus vite, j'ai pris le parti d'utiliser Tofu d'Alessandro Ghedini. Le projet est récent, purement expérimental, mais démontre le type d'API que peut proposer une bibliothèque C pour des applications web.

Tofu est un projet qui me semble intéressant dans la mesure où il supporte plusieurs backends, pour n'en citer que deux :

zmq, qui lui permet de tourner derrière un certain mongrel2,
ou, plus simplement, la libevent, qu'on va sagement utiliser pour notre petit PoC.

Dans d'autres contextes que celui-ci, ce ne serait donc pas une brique monolithique déterminant toute une architecture, mais bien un élément qui pourrait s'intégrer avec d'autres. C'est un détail qui mérite d'être souligné.

Nous allons construire un service HTTP simplissime. Ce dernier va répondre sur une URL du type http://server/hello/af83, avec le JSON {"hello": "af83"}.

Commençons par créer un fichier hello.c. Pour utiliser les fonctions de Tofu, on doit inclure le header tofu.h, et pour parler JSON sans bégayer, jansson.h.

#include <tofu.h>
#include <jansson.h>

int main(int argc, char ** argv) {
    return 0;
}

Pour récupérer la dernière version de Tofu, un rapide git clone https://github.com/AlexBio/Tofu.git devra faire l'affaire. Après quoi il faudra suivre le README de la bibliothèque pour la compiler avec vos petites mimines, et finalement soit l'installer sur votre système, soit jouer avec les flags -I et -L de gcc pour linker votre programme…

C'est là qu'un outil comme go get nous faciliterait bien la vie !

Pour initialiser Tofu, dans notre fonction main, on fera :

// Initialise le serveur HTTP sur le port TCP 8080.
char *opts[] = { "0.0.0.0", "8080" };
tofu_ctx_t *ctx = tofu_ctx_init(TOFU_EVHTTP, opts);

// Lance le serveur HTTP, et bloque le programme.
tofu_loop(ctx);

Si vous compilez votre programme en l'état, vous obtiendrez un serveur HTTP des plus inutiles qui ne répondra que par des erreurs 404 quelle que soit l'URL accédée. C'est pas encore ça.

Tofu permet d'assigner des callbacks à des URL statiques, ou dynamiques. Dans cet exemple, on aimerait, lorsqu'on accède à /hello/af83, obtenir le JSON {"hello": "af83"}. On peut d'ores et déjà relier l'URL attendue à une tierce fonction en utilisant tofu_handle_with :

// à placer *avant* l'appel bloquant à tofu_loop, hein ;)
tofu_handle_with(ctx, GET, "/hello/:name", hello, 0x0);

Pour répondre sur cette URL, il nous faut définir le callback hello mentionné dans le code. Il doit renvoyer un pointeur du type tofu_rep_t, et accepter deux arguments :

// voilà un callback "hello" minimal...
tofu_rep_t *hello(tofu_req_t *req, void *argp) {
    tofu_rep_t *rep = tofu_rep_init();
    return rep;
}

Notre serveur HTTP ne renvoie plus d'erreur 404 sur /hello/af83, mais répond avec rien, ce qui est bien mais pas top. Pour bien faire, on va récupérer le paramètre name qu'on a créé avec tofu_handle_with : Tofu a le bon goût de fournir tofu_param pour ça.

char *param = tofu_param(req, "name");

On pourrait alors construire une réponse JSON « à la main » avec les informations qu'on a récupérées. Mais pourquoi se priver d'utiliser la lib Jansson qui sait échapper les caractères spéciaux, et construire du JSON propre ?

// `obj` est un objet JSON vide, soit : {}
json_t *obj = json_object();

// obj a désormais une clef "hello", qui reprend la valeur de param.
// Par exemple: {"hello": "af83"}
json_object_set(obj, "hello", json_string(param));

// `json_dumps` encode `obj` pour en faire une chaîne de caractères.
char *reply = json_dumps(obj, JSON_ENSURE_ASCII);

Il nous reste à mettre tout ça en forme pour répondre, à l'aide de tofu_head, et de tofu_write. L'exemple complet est disponible sur un Gist. Si vous êtes assez curieux pour y jeter un œil, vous vous rendrez compte qu'en à peine quelques lignes de C, on peut faire pas mal de choses…

Ce court billet pourrait illustrer une question que se posent souvent les développeurs (du moins on l'espère) : est-ce que j'utilise le bon outil pour ce boulot ?

Le C par exemple est un langage formidable pour écrire des programmes qu'on dit de « bas-niveau » (un serveur DNS, un kernel, une machine virtuelle, …), Go en est un autre. Pour du web en revanche, vous serez beaucoup mieux servis par des langages dynamiques comme Ruby, ou Javascript. S'il est donc facile (et surtout divertissant :p) d'écrire des petites applications web comme celle-ci en C, ça n'est que rarement souhaitable.

Écrire un service web en Go

2012-04-07T00:00:00+02:00

Après avoir fait nos premiers pas avec Go, il est temps de passer à l'écriture d'un vrai programme. Je vous propose de faire un service web vraiment simple : il reçoit des requêtes HTTP et y répond un Hello world en JSON.

Commençons par créer un fichier hello.go. Tout fichier contenant du code Go doit indiquer de quel package il fait partie. Dans notre cas, nous allons utiliser le package main, qui est un package particulier : la fonction main définie dans ce package sera exécutée lorsque l'on lance le programme.

package main

Ensuite, nous importons deux packages provenant de la bibliothèque standard de Go : io et net/http. Le premier sert pour toutes les opérations d'entrées/sorties et le second pour faire des clients et des serveurs HTTP.

import (
    "io"
    "net/http"
)

Nous avons indiqué plus haut que la fonction main de notre package serait exécutée au lancement du programme… Il est temps de l'écrire. En go, la déclaration d'une fonction se fait avec le mot clé func et la syntaxe ressemble au C ou au JavaScript : les arguments sont listés entre parenthèses, et le corps de la fonction entre accolades.

func main() {
    // Le corps de la fonction
}

Dans notre cas, nous voulons faire deux choses dans la fonction main : démarrer un serveur HTTP et lui dire que l'on reçoit une requête - celle-ci devra être traitée par la fonction HelloWorld. Le module net/http nous fournit de quoi faire cela simplement en deux lignes :

func main() {
    http.HandleFunc("/", HelloWorld)
    http.ListenAndServe("127.0.0.1:8000", nil)
}

Il ne reste plus qu'à écrire la fonction HelloWorld. Pour le moment, nous allons renvoyer une chaîne de caractères en dur, la version évoluée sera pour plus tard. Les chaînes de caractères peuvent être délimitées par des doubles quotes ou par des backquotes. Nous allons préférer la seconde forme pour pouvoir mettre facilement des doubles quotes à l'intérieur :

`{"hello":"world"}`

Mais revenons à notre fonction HelloWorld. Pour être compatible avec le module net/http, elle doit prendre deux paramètres, le premier étant du type http.ResponseWriter et le second du type *http.Request (la petite étoile sert à indiquer que c'est un pointeur). Les personnes qui ont fait du C ou du Java risquent d'être surprises mais, en Go, le type vient toujours après le nom de la variable.

À l'intérieur de notre fonction, nous allons simplement utiliser io.WriteString pour écrire la réponse dans le http.ResponseWriter :

func HelloWorld(w http.ResponseWriter, req *http.Request) {
    io.WriteString(w, `{"hello":"world"}`)
}

Voilà, nous avons un programme fonctionnel. Il peut se lancer avec go run hello.go (ça compile le programme puis exécute la version compilée). Et on peut vérifier avec curl qu'il fonctionne :

% curl -v http://localhost:8000/
* About to connect() to localhost port 8000 (#0)
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 8000 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.21.6 (i686-pc-linux-gnu) libcurl/7.21.6 OpenSSL/1.0.0e zlib/1.2.3.4
> Host: localhost:8000
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sat, 07 Apr 2012 18:35:14 GMT
< Transfer-Encoding: chunked
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host localhost left intact
* Closing connection #0
{"hello":"world"}

Maintenant que vous avez pu constater qu'il est très facile de créer un serveur HTTP en Go, nous allons voir comment l'améliorer et ainsi découvrir de nouvelles fonctionnalités de Go. Il pourrait par exemple être pratique de pouvoir spécifier l'interface et le port sur lequel notre serveur écoute.

Pour extraire des arguments de la ligne de commande, la bibliothèque standard de Go propose le module flag. Nous allons déclarer une variable addr de type string, puis utiliser le module flag pour la remplir à partir de la ligne de commande ou, à défaut, avec une valeur par défaut. Cela donne ces quelques lignes :

var addr string
flag.StringVar(&addr, "addr", "127.0.0.1:8000", "Bind to this address:port")
flag.Parse()
http.ListenAndServe(addr, nil)

Nous pouvons maintenant compiler notre programme et le lancer en lui passant l'option -addr. Au passage, notez que notre programme dispose aussi de l'option -h pour afficher l'aide :

% go build hello.go
% ./hello -h
Usage of ./hello:
  -addr="127.0.0.1:8000": Bind to this address:port
% ./hello -addr=:7000

Étape suivante : la gestion des erreurs. La fonction ListenAndServe peut échouer pour différentes raisons. Si on lance notre programme en simple utilisateur en lui demandant d'écouter sur un port inférieur à 1024, cet appel échouera parce que nous n'avons pas les droits suffisants.

En go, la gestion des erreurs se fait principalement en retournant une erreur ou nil quand tout va bien. Nous allons utiliser le module log (n'oubliez pas de l'ajouter à l'import) pour afficher l'erreur et mettre fin au programme :

err := http.ListenAndServe(addr, nil)
if err != nil {
    log.Fatal("ListenAndServe: ", err)
}

Cela donne cette sortie :

% ./hello -addr=:1
2012/04/07 20:51:21 ListenAndServe: listen tcp <nil>:1: permission denied

Il nous reste encore deux choses à voir : la première est de remplacer la chaîne de caractères en dur qui représente le JSON et la seconde de faire du routage dynamique sur les URL. Pour le JSON, la bibliothèque standard de Go répond une fois de plus à nos attentes en fournissant un module encoding/json.

Mais avant de l'utiliser, nous allons voir comment déclarer un nouveau type. Nous allons créer un type Response qui permettra d'avoir notre réponse sous forme structurée avant d'être encodée en JSON. Le mot-clé type prend d'abord le nom du nouveau type puis la définition du type. Cette définition peut être un type simple, comme int, ou un type composé. Dans notre cas, ce sera un struct avec un seul champ : Hello.

type Response struct {
    Hello string
}

Nous modifions maintenant notre fonction HelloWorld pour créer une variable de type Response puis l'encoder en JSON :

func HelloWorld(w http.ResponseWriter, req *http.Request) {
    var response Response
    response.Hello = "world"
    b, err := json.Marshal(response)
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }
    io.WriteString(w, string(b))
}

Notons que les fonctions en Go peuvent renvoyer plusieurs éléments. C'est le cas de la fonction json.Marshall qui renvoie un tableau de bytes et une erreur. C'est très pratique car cela évite de devoir faire comme en C pour un retour qui peut à la fois être le résultat de la fonction et indiquer une erreur.

Quand une erreur se présente, nous la traitons en renvoyant une erreur 500 avec le message de l'erreur grâce à la fonction http.Error.

D'autre part, WriteString attend en deuxième paramètre une chaîne de caractères, pas un tableau de bytes. Nous faisons donc la conversion avec string(b).

Nous pouvons donc passer à la dernière évolution de notre programme : gérer des URL dynamiques. Plutôt que de répondre toujours Hello world, nous pourrions passer le nom en paramètre dans l'URL. Par exemple, un GET sur /hello/Bruno renverrait {"Hello":"Bruno"}.

Pour cela, nous utilisons un module externe, pat, écrit par Keith Rarick et Blake Mizerany (si ce nom vous est familier, c'est probablement car il est aussi l'auteur de Sinatra). Go permet d'utiliser très simplement des modules provenant de diverses sources. L'installation du module se fait d'un simple appel à go get github.com/bmizerany/pat. Ensuite, nous pouvons importer notre module en l'ajoutant à la liste des imports :

import (
    "encoding/json"
    "flag"
    "github.com/bmizerany/pat"
    "io"
    "log"
    "net/http"
)

Nous déclarons ensuite notre route dans la fonction main, à la place du http.HandleFunc :

m := pat.New()
m.Get("/hello/:name", http.HandlerFunc(HelloWorld))
http.Handle("/", m)

Et il ne reste plus qu'à récupérer le paramètre :name dans la fonction HelloWorld et à l'injecter dans notre variable response :

response.Hello = req.URL.Query().Get(":name")

Et voilà, nous pouvons maintenant tester le tout :

$ go run hello.go -addr=:7000
$ curl http://localhost:7000/hello/Bruno
{"Hello":"Bruno"}

J'espère que ce billet vous aura permis d'apprécier la simplicité de Go et vous aura donné envie d'aller plus loin avec. En attendant, vous pouvez consulter le code complet sur ce gist.

Faire ses premiers pas avec Go

2012-04-02T00:00:00+02:00

On entend régulièrement parler de langages de programmation qui sont présentés comme des remplaçants du bon vieux C… Go est l'un de ces langages. Initialement commencé comme un projet interne à Google par une équipe notamment composée de Rob Pike et Ken Thomson (excusez du peu), il a rapidement dépassé ce cadre et est maintenant soutenu par une importante communauté Open-Source.

La sortie d'une première version stable, Go 1, va permettre à de nombreux développeurs d'envisager plus facilement l'utilisation de Go au regard des contraintes de production. Ça ne veut pas dire que le langage n'était pas utilisé en production jusque là, mais ses évolutions engendraient un coût pour maintenir les applications. D'ailleurs, Go peut d'ores et déjà se prévaloir de quelques très belles références : Google utilise Go au coeur de l'infrastructure de Youtube, sous la forme d'un proxy/multiplexer SQL nommé vitess (publié sous licence BSD). On peut également citer Heroku, Canonical et d'autres qui font confiance à Go pour des services importants de leurs infrastructures.

Ces exemples montrent que Go peut effectivement s'avancer comme un successeur du C, mais il serait trompeur de croire qu'il va entièrement remplacer le C et tous ses cas d'usage. Typiquement, je ne pense pas que Go soit particulièrement intéressant pour développer le noyau d'un système d'exploitation ou faire des systèmes embarqués avec des contraintes temps-réel et des ressources fortement limitées. Par contre, Go me paraît être extrêmement pertinent pour faire des daemons réseaux ou des services nécessitant fiabilité et performances ; en particulier, la combinaison des goroutines et channels semble très efficace pour construire des systèmes concurrents sans s'arracher les cheveux.

Mais le mieux est encore de vous montrer ce à quoi ressemblent des programmes en Go. Après tout, le titre de ce billet est « Faire ses premiers pas avec Go »…

La première étape consiste à installer Go. Si vous utilisez une distribution Linux, il y a fort à parier qu'elle fournit des paquets pour Go (c'est le cas d'Ubuntu par exemple). Dans le cas contraire, pas d'inquiétude, vous pourrez trouver des exécutables pour Windows, Linux, OSX et FreeBSD, ainsi que les sources. Et pour finir l'installation, il faudra définir quelques variables d'environnement (à ajouter à ~/.zshrc si vous utilisez zsh, ou son équivalent si vous utilisez un autre shell) :

export GOROOT="/usr/lib/go"
export GOPATH="$HOME/go"
export PATH="$PATH:$GOPATH/bin:$GOROOT/bin"

La première variable, GOROOT, sert aux outils de compilation pour savoir où Go est installé (notamment la bibliothèque standard). Par défaut, cela devrait être /usr/local/go mais, dans mon cas, le paquet Ubuntu a installé ça dans /usr/lib/go.

Ensuite, vient GOPATH. Cette variable va permettre d'aller chercher le code de diverses bibliothèques pour la compilation. Le premier répertoire listé joue un rôle particulier : il accueillera les bibliothèques installées avec la commande go install (je n'en dirais pas plus aujourd'hui, cela mérite un billet de blog à part).

Enfin, on ajoute nos chemins au $PATH pour pouvoir lancer les commandes Go sans avoir à taper les chemins complets.

L'étape suivante consiste à configurer son éditeur de texte favori. Vous avez le droit de sauter ce passage mais, pour moi, prendre 5 minutes pour faire cela permet de gagner bien plus de temps ensuite. Pour Vim, cela peut se limiter à ajouter ces 3 lignes à son ~/.vimrc dans un premier temps :

set rtp+=$GOROOT/misc/vim
filetype plugin indent on
syntax on

Comme vous pouvez le constater, Go est fourni de base avec des plugins pour différents outils. Vous pouvez en faire le tour dans le répertoire $GOROOT/misc. Et pour aller plus loin, http://go-lang.cat-v.org/text-editors/ est une ressource incontournable.

Il est maintenant temps de tester notre installation avec le très célèbre Hello World. Nous allons donc créer un fichier hello.go avec les 5 lignes suivantes :

package main

import "fmt"

func main() {
    fmt.Printf("Hello world\n")
}

Puis, nous allons compiler et lancer le programme en une seule commande :

go run hello.go

Si vous voyez Hello world, félicitations, votre installation de Go fonctionne et vous avez fait tourner votre premier programme dans ce langage. Pour continuer, je vous conseille de faire Le tour de Go ou de passer à l'écriture d'un service web en Go.

Les espaces insécables pour les codeurs

2012-03-20T00:00:00+01:00

Il m'est arrivé une mésaventure avec les espaces insécables. Ce n'est pas la première fois, mais à chaque fois, je me dis que je ne me laisserais plus avoir.

Commençons par le début : qu'est-ce qu'une espace insécable ? C'est un caractère qui s'affiche comme une espace normale mais qui empêche de faire un retour à la ligne à cet endroit. Par exemple, en bon français, on met une espace insécable avant des « : », et ainsi ceux-ci se trouvent attachés avec le mot juste avant et ne peuvent pas se retrouver en début de ligne. Je vous conseille la lecture de l'article wikipédia sur ce sujet si vous souhaitez en savoir plus.

En pratique, il est facile d'en mettre dans du HTML : c'est la fameuse entité   (pour non-breaking space). Les traitements de texte savent aussi les insérer au bon endroit pour vous. Et il est possible d'en insérer manuellement avec une combinaison du clavier, qui dépend du système d'exploitation et de la disposition du clavier. Sous GNU/Linux, la combinaison souvent utilisée pour ça est Alt gr + espace. Ainsi, lorsque l'on est en train de taper une suite de commandes avec des pipes, on peut se retrouver très facilement avec une espace insécable si on a le malheur de garder le doigt appuyé sur la touche Alt grun poil trop longtemps. On se retrouve alors avec un message qui a de quoi laisser perplexe :

% ls | grep foo
command not found:  grep

Je me suis fait avoir un paquet de fois, jusqu'à désactiver la saisie des espaces insécables en ajoutant cette ligne au fichier ~/.xmodmaprc :

keycode 65 = space space space space space

Ça suffit pour éviter que je ne saisisse des espaces insécables, mais je me suis alors rendu compte que d'autres développeurs pouvaient eux aussi saisir des espaces insécables dans du code. J'ai donc configuré mon éditeur, vim, pour afficher les espaces insécables :

set listchars=trail:◃,nbsp:•
set list

Et malgré ça, je me suis encore laissé avoir. J'ai récupéré un fichier CSV avec des villes, avec diverses informations sur chaque ville dont la population. J'importe les données et je me rends alors compte que Bordeaux fait 448 habitants. Un rapide coup d'oeil au fichier CSV avec less et je découvre que des espaces sont utilisées comme séparateur des milliers pour la population. Je remplace alors mon code par :

population = row.last.gsub(/\s/, '').to_i

Ça supprime les espaces, tabulations et retours à la ligne avant de convertir en entier. Confiant, je relance mon script et, surprise, ça ne marche toujours pas ! J'ai fait un petit tour des erreurs classiques : vérifier que j'ai bien la bonne valeur dans row.last, bien vider la base de données avant de réessayer, etc. Rien n'y fait. Je lance un interpréteur Ruby et je tape :

"448 144".gsub(/\s/, '').to_i
# => 448144

Ça devrait bien marcher, et pourtant ça ne marche pas. Alors, vous avez deviné d'où venait le problème ? Le séparateur des milliers n'était pas une simple espace mais une espace insécable… Une fois la source trouvée, la correction fut simple :

population = row.last.gsub(/[[:blank:]]/, '').to_i

Mais, amis codeurs, méfiez-vous des espaces insécables !

Découvrons le module Shellwords pour Ruby

2012-03-14T00:00:00+01:00

La bibliothèque standard de Ruby comporte pas mal de modules vieillissants, dont le code aurait plus sa place dans des gems à part. Mais on peut aussi y trouver quelques perles. Je vous ai déjà parlé des Set et des Struct. Aujourd'hui, je vais compléter cette liste, en y ajoutant Shellwords.

La description de Shellwords dit :

This module manipulates strings according to the word parsing rules of the UNIX Bourne shell.

Ce que l'on pourrait traduire en français par :

Ce module manipules des chaînes de caractères en respectant les règles des shells Bourne UNIX pour découper les mots.

La première utilisation de ce module est de pouvoir construire des lignes de commande pour le shell. Par exemple, si on veut compter le nombre de lignes d'un fichier, on peut faire :

filename = "/path/to/my/file"
nb_lines = `wc -l < #{filename}`.to_i

Mais, si pour une raison ou une autre, le nom de fichier comporte une espace, cela ne va plus marcher. Dans la ligne de commande, l'espace se comportera comme un séparateur de mots et le shell va chercher deux fichiers au lieu d'un. Pour corriger le problème, on peut faire appel à Shellwords de cette façon :

require "shellwords"

filename = "/path/to/my/file"
nb_lines = `wc -l < #{Shellwords.escape(filename)}`.to_i

Note : l'espace n'est pas le seul caractère à poser problème dans les lignes de commande du shell. On peut également citer les retours à la ligne, les guillemets, l'anti-slash, le point-virgule (qui sert à séparer des instructions) ou encore le dollar (pour référencer des variables).

Si vous avez un tableau, il existe également une petite méthode utilitaire pour vous aidez, Shellwords.join. Voici un exemple :

require "shellwords"

pattern = "foo bar"
files = %w(some files)
open('|' + Shellwords.join(['grep', pattern, *files])) { |pipe|
  # ...
}

Cette méthode applique Shellwords.escape sur chaque élément du tableau, puis fais un join(' ') pour construire cette partie de la ligne de commande finale.

On a vu comment construire une ligne de commande à partir de mots, mais la réciproque est également valable : Shellwords peut aussi nous aider à découper en mots une ligne de commande. Exemple :

require "shellwords"

argv = Shellwords.split('here are "two words"')
argv #=> ["here", "are", "two words"]

Cette méthode peut s'avérer bien pratique, même en dehors du contexte du shell. Imaginer que vous ayez un système qui permette de saisir des tags séparés par des espaces :

tags = gets.split(' ')

Si l'utilisateur saisit la ligne Ruby Shell Tips, tags sera le tableau avec les 3 tags : ["Ruby", "Shell", "Tips"]. Puis, un utilisateur vous remonte son besoin de saisir des tags avec des espaces dedans, comme Open Source ou Free Software. Vous ne voulez pas changer le séparateur, juste avoir un moyen d'indiquer si l'espace fait parti du tag ou non. Le shell a déjà résolu ce problème pour vous. Il propose deux façons de saisir un mot avec des espaces : soit le mettre entre des guillemets, soit utiliser le caractère d'échappement \. Et avec Shellwords, c'est très facile de proposer le même mécanisme :

require "shellwords"
tags = Shellwords.split(gets)

Et maintenant, si l'utilisateur saisit la ligne "Free Software" Open\ Source, nous obtenons bien un tableau avec deux tags : ["Free Software", "Open Source"]. Ne trouvez-vous pas que c'est une utilisation bien pratique de Shellwords ?

Vagrant with Rails + ES + Redis

2012-03-05T00:00:00+01:00

Nous utilisons pour plusieurs projets une stack rails + ElasticSearch + Redis.

Pour avoir rapidement une machine virtuelle sur un projet, nous avons choisi vagrant avec chef-solo.

La première chose à faire est d'installer VirtualBox, sur une Debian :

aptitude install virtualbox virtualbox-dkms virtualbox-qt \
    virtualbox-source linux-headers-2.6-amd64 module-assistant 

modprobe vboxdrv
adduser YOU vboxusers
/etc/init.d/virtualbox restart

Puis on configure la box :

gem install vagrant chef

vagrant box add debian-squeeze-64-rvm https://s3-eu-west-1.amazonaws.com/rosstimson-vagrant-boxes/debian-squeeze-64-rvm.box

vagrant init debian-squeeze-64-rvm
vagrant up

Pour utiliser chef-solo, il faut également avoir un fichier de configuration knife :

.chef/knife.rb

# encoding: UTF-8
cookbook_path [ File.expand_path('../../cookbooks', __FILE__) ]

On peut maintenant installer des cookbooks :

knife cookbook site install nginx

Que l'on ajoute ensuite au Vagrantfile :

config.vm.provision :chef_solo do |chef|
  chef.cookbooks_path = "cookbooks"
  chef.add_recipe "nginx"
end

Finalement, on relance l'ajout de recettes avec :

vagrant provision

Les recettes utiles :

How to extend the Redcarpet 2 Markdown library?

2012-02-27T00:00:00+01:00

As you may now, this blog is powered by Jekyll, and the posts on it are written in Markdown (by the way, you should adopt the Markdown Mindset). But by default, the markdown parser for Jekyll doesn't understand the fenced code blocks that Github Flavored Markdown introduced. And as a daily user of Github, it was something that I really wanted.

So I wrote a plugin for Jekyll based on the redcarpet library which adds this feature and some others. Redcarpet is a very nice library for parsing Markdown and rendering HTML from it. Since the version 2 Vicent Martí, its author, has decoupled the parser and the renderer, making it fairly easy to extend.

This post explains how to do that and sidestep some traps. But, first, let's see the basic usage of Redcarpet. It works in two steps:

Create a markdown object, with a given renderer.
Give it a markdown text with the render method and it will return you an HTML document.

For example, if you want to use the Redcarpet::Render::HTML renderer (it's one of the renderers that came out of the box with Redcarpet), you can do:

markdown = Redcarpet::Markdown.new(Redcarpet::Render::HTML, :fenced_code_blocks => true)
markdown.render("This is *bongos*, indeed.")
# => "<p>This is <em>bongos</em>, indeed</p>"

The first level of personalization of Redcarpet is the extensions that you can give to the Redcarpet::Markdown constructor. In the previous example, we enabled the :fenced_code_blocks extension that makes it parse blocks of code delimited with 3+ ~ or backticks. These extensions modify the way Redcarpet parses the markdown input.

For the output, you can change the first argument: the renderer. In our example, we used a class, but you can also give an instance instead. And this is particullary useful, as Redcarpet::Render::HTML accepts options for its constructor.

Let's see an example:

renderer = Redcarpet::Render::HTML.new(:no_links => true, :hard_wrap => true)
markdown = Redcarpet::Markdown.new(renderer)
markdown.render("This is foo.\nThat is bar.")
# => "<p>This is foo.<br>\nThat is bar.</p>\n"

One of the available options, :with_toc_data, is not that obvious to use. If you want to generate an HTML document with its table of contents, you'll have to render your document 2 times:

html_toc = Redcarpet::Markdown.new(Redcarpet::Render::HTML_TOC)
markdown = Redcarpet::Markdown.new(Redcarpet::Render::HTML.new(:with_toc_data => true))
toc  = html_toc.render(text)
html = markdown.render(text)
full = toc + html

So, how does it work? The first time, we use a special renderer, Redcarpet::Render::HTML_TOC, which renders only the table of contents. Then, we do a second pass to generate the body of the document with anchors on the titles (this is what the :with_toc_data option does).

You can go further with a renderer tailored for your fancy needs. It's not complicated, all you have to do is inheriting from Redcarpet::Render::Base and implementing the callbacks listed on the README. An example of this is given to render Manpages.

However, there is a faster way to render HTML: you can inherit from Redcarpet::Render::HTML and just overload some callbacks! The canonical example is highlighting code:

class HTMLwithAlbino < Redcarpet::Render::HTML
  def block_code(code, language)
    Albino.safe_colorize(code, language)
  end
end

markdown = Redcarpet::Markdown.new(HTMLwithAlbino, :fenced_code_blocks => true)

But let's try another example: you want to use the headers from <h2>, not <h1>. So let's do with our own header method:

class OurHTML < Redcarpet::Render::HTML
  def header(text, level)
    level += 1
    "<h#{level}>#{text}</h#{level}>"
  end
end

Our implementation doesn't seem to be optimal. You may be tempted to use super like this:

class OurHTML < Redcarpet::Render::HTML  # WON'T WORK
  def header(text, level)                # WON'T WORK
    super(text, level + 1)               # WON'T WORK
  end                                    # WON'T WORK
end                                      # WON'T WORK

Please be warned that you can't do that. To offer the maximum performances, the readcarpet library is coded mostly in C with some optimizations. One of these optimization is the way the Redcarpet::Render::HTML methods are called from the library and it has the nasty side-effects that super won't work. An issue is opened if you want to discuss about that.

Still, it's possible to use super on the constructor, for enabling an option by default - for example:

class HardWrappedHTML < Redcarpet::Render::HTML
  def initialize(options={})
    super options.merge(:hard_wrap => true)
  end
end

To conclude, Redcarpet is my favourite library for manipulating Markdown: it offers some options for common customizations and can be extended easily.

Structurez votre code Ruby

2012-02-20T00:00:00+01:00

Pour continuer avec les structures de données présentes dans la bibliothèque standard de Ruby, après les Sets, je souhaite vous présenter les Struct. Cette structure permet de créer une sorte de classe légère avec quelques attributs.

Voyons un exemple :

Struct.new("Customer", :name, :address)
customer = Struct::Customer.new("Dave", "123 Main")
customer.name         # -> "Dave"
customer.address      # -> "123 Main"
customer.name = "Joe"
customer.name         # -> "Joe"

À la première ligne, on définit notre structure, avec d'abord son nom, suivi de la liste des attributs. Cette structure sera ensuite accessible via Struct::Customer. À la ligne suivante, on instancie un objet en lui passant les paramètres dans le même ordre que les attributs lors de la définition de la structure. Enfin, on peut utiliser les attributs sur cet objet comme pour une classe normale où ils auraient été définis avec un attr_accessor.

Une première propriété bien sympatique des Struct est de pouvoir accéder aux attributs comme si cet objet était un Hash :

Struct.new("Customer", :name, :address)
customer = Struct::Customer.new("Dave", "123 Main")
customer[:name]          # -> "Dave"
customer[:name] = "Joe"
customer.name            # -> "Joe"

Et l'autre caractérisque que j'apprécie particulièrement chez les Struct est que le constructeur renvoie la classe. Cela permet, par exemple, de l'assigner à une autre constante sans le namespace Struct:: :

Customer = Struct.new("Customer", :name, :address)
customer = Customer.new("Dave", "123 Main")

Dans ce cas, on peut également se passer de passer le nom de la structure en premier paramètre :

Customer = Struct.new(:name, :address)
customer = Customer.new("Dave", "123 Main")

Mais surtout, je l'utilise souvent pour hériter d cette classe. Voici un exemple pris depuis ma gem guide-em-up :

class Index < Struct.new(:root, :current_dir, :data_dir, :themes)

  def html
    file = File.join(data_dir, "/browser.erb")
    tmpl = File.read(file)
    Erubis::Eruby.new(tmpl).result(to_hash)
  end

# ...
end

Dans le même style, Ruby possède des OpenStruct, qui sont un mélange entre les Struct et les Hash. Voici un exemple d'utilisation :

require 'ostruct'
person = OpenStruct.new(:first_name => "John", :last_name => "Doe")
person.age = 42
puts "#{person.first_name} #{person.last_name} a #{person.age} ans."
# -> "John Doe a 42 ans."

Note : par contre, il n'est pas possible d'utiliser la syntaxe de type Hash pour accéder aux attributs d'un OpenStruct. Dommage…

Au final, on ne rencontre pas souvent Struct et OpenStruct quand on lit du code Ruby. Mais ils peuvent être bien pratiques, et c'est pourquoi, je pense que c'est une bonne idée de les connaître. Ils m'ont déjà rendu bien des services par le passé et j'espère que vous pourrez en dire autant dans quelques temps.

Remplacez Resque par Sidekiq

2012-02-16T00:00:00+01:00

Lorsque l'on développe des applications web, il est souvent recommandé de répondre rapidement aux requêtes HTTP. En particulier, il faut éviter que les traitements lourds, comme l'encodage d'une vidéo ou la génération de vignettes, bloquent les réponses. Pour cela, la solution classique est d'utiliser un message queue. Le plus populaire dans le monde Rails est Resque (avec la base de données clé-valeur Redis comme stockage).

Le principe est simple : on définit des traitements à faire et quand l'application Rails souhaite faire un de ces traitements, elle place dans Redis un ordre. D'autres processus, les workers, prennent un ordre dans Redis, l'effectuent, puis passent à l'ordre suivant.

Chez af83, nous utilisons Resque sur plusiers projets et nous en sommes très satisfaits. Toutefois, Resque a un défaut : chaque worker traite un seul ordre à la fois et consomme pas mal de mémoire. Dans la pratique, cela veut souvent dire que l'on ne pourra pas traiter plus d'une dizaine d'ordres simultanément.

Sidekiq a été écrit spécialement pour dépasser cette contrainte. C'est un remplaçant de Resque écrit avec Celluloid, une bibliothèque d'Actors en Ruby. Dans Sidekiq, les workers sont des threads et non plus des processus, permettant de consommer beaucoup moins de mémoire par worker et donc d'en faire fonctionner beaucoup plus en parallèle.

En pratique, si on souhaite utiliser Sidekiq sur un projet Rails, on commence par l'ajouter au Gemfile :

gem 'sidekiq'

Puis, on écrit un worker (dans le répertoire app/workers), avec une méthode perform :

class MetricsWorker
  include Sidekiq::Worker

  def self.perform(action, count=1)
    Metrics.increment(action, count)
  end
end

Enfin, on peut utiliser ce worker depuis un contrôleur ou un modèle, en utilisant la méthode perform_async :

Metrics.perform_async("start", 1)

Il ne reste plus qu'à lancer sidekiq depuis la racine de Rails pour que celui-ci commence à récupérer les ordres et les traiter.

Bref, Sidekiq peut remplacer avantageusement Resque et ce d'autant plus facilement qu'il utilise le même stockage. Il est même possible d'utiliser resque-ui avec Sidekiq (il suffit d'indiquer à sidekiq d'utiliser le namespace resque pour redis en le lançant de cette façon : sidekiq -n resque).

Dernière chose, Sidekiq est distribuée sous 2 licences : GPLv3 et commerciale. Si la licence GPL vous convient, tant mieux, utilisez-là. Dans le cas contraire, vous pouvez payer 50$ à Mike Perham pour pouvoir utiliser Sidekiq (ça doit lui permettre de passer plus de temps sur ses projets Open Source).

Mise à jour : attention, Mongoid 2.x n'est pas thread-safe et il est donc très fortement déconseillé de l'utiliser avec Sidekiq. La version 3 de Mongoid est en cours de développement et sera thread-safe. Source : https://github.com/mongoid/mongoid/issues/1291

Présentation de 45 projets en 45 minutes aux TechDays

2012-02-07T00:00:00+01:00

Comme annoncé hier, j'ai fait une présentation intitulée « 45 projets en 45 minutes ». L'idée de cette présentation est de parler d'un large éventail de projets web ou dans des langages de programmation Open Source pour inspirer les auditeurs, leur donner de nouvelles idée, l'envie d'utiliser ces projets, voir d'y contribuer.

Vous pouvez regarder les slides ou juste consulter la liste des projets présentés :

Quelques événements où vous pourrez nous rencontrer

2012-02-06T00:00:00+01:00

Comme vous le savez sûrement déjà, af83 a une participation très active dans les communautés, et notamment dans les événements qu'elle organise, sponsorise ou prend part d'une façon ou d'une autre. Voici quelques événements où vous pourrez nous rencontrer si vous le souhaitez.

Ce soir, quelqu'uns d'entre nous iront au meetup Paris.rb.

Demain, je serai présent au Microsoft TechDays pour présenter 45 projets en 45 minutes.

Ensuite, nous participerons au prochain Paris.js et au Paris Opa Devcamp #1 organisé par MLState, Placeloop et Geeklist (au fait, vous pouvez nous rejoindre sur geeklist).

Au mois d'avril, rien de sûr, mais nous avons proposé des talks à Devoxx et www2012.

Enfin, nous ne manquerons pas les Rencontres Mondiales du Logiciel Libre à Genève. Et il se murmure que nous pourrions organiser un prochain Web Workers Camp ;-)

Soyez unique, utilisez des Sets

2012-02-03T00:00:00+01:00

En Ruby, on utilise très souvent les deux structures composites que sont les tableaux et les hashs. Mais la bibliothèque standard ne se limite pas à ces deux là.

Je fais toujours une grimace quand je vois du code qui ressemble à ça :

foos = []
data.each do |data|
  foo = transform(data)
  foos << foo unless foos.include?(foo)
end
do_something_with(foos)

Ce code construit un tableau d'objets sans doublon. Pour cela, avant d'insérer un élément dans le tableau, il vérifie que celui-ci n'est pas déjà présent dans le code.

Or, pour ce besoin précis, Ruby propose des Sets, c'est-à-dire un ensemble non ordonné d'éléments uniques. L'exemple précédent devient :

require "set"
foos = Set.new
data.each do |data|
  foos << transform(data)
end
do_something_with(foos)

Les Sets sont des Enumerables qui s'utilisent un peu comme des tableaux, mais qui évitent tout doublon :

require "set"
foos = [3, 2, 1].to_set
foos << 2
foos  # ~> #<Set: {3, 2, 1}>

En dehors de l'aspect pratique, les Sets sont également plus performants que les tableaux pour ce cas d'usage. Dans le cas du tableau, avant d'ajouter un élément, il faut parcourir tout le tableau pour vérifier que l'élément n'est pas déjà présent. Par contre, les Sets utilisent des Hashs pour le stockage et le temps d'insertion d'un élément ne dépendra pas du nombre d'éléments dans le Set.

Une variante intéressante des Sets sont les SortedSets. Ils sont similaires aux Sets mais garantissent que l'on accède à leurs éléments dans l'ordre. Ce sera sûrement plus clair sur un exemple :

require "set"
foos = SortedSet.new
foos << 3
foos << 1
foos << 2
foos << 2
foos.to_a  # ~> [1, 2, 3]

Voilà, j'espère que la prochaine fois que vous aurez besoin d'une collection d'éléments uniques, vous penserez à utiliser les Sets pour m'éviter une grimace le jour où j'irais lire votre code sur github ;-)

Writing a blog post – 101 Introductory Class

2012-02-01T00:00:00+01:00

Recently I was asked to contribute to the devblog… Since I don’t code, Bruno suggested I’d talk about how to write nice content. So here are a few pieces of advice for your blog articles:

Find something to talk about where you actually have something to say – yes, you do have one: feedback on tools, languages, events you attended, opinion on methodologies, cool stuff you just coded, questions for the community…

Start with an MVP, that is to say your idea plus the main points, and only then begin writing up. Don’t be afraid of refactoring, you probably won’t say it the way you want to on the first draft.

KISS and DRY doesn’t only apply only to code. You’re not writing a novel, and there’s no reward for the longest post on the internet. So go straight to the point, and don’t lose your reader in phrases that look like paragraphs.

If it keeps being too long, maybe you’re trying to fit too much information in your message: use packets, and break it in smaller parts with indications for the reader to retrieve the other parts of the message.

Respect the language conventions so your post will be parsed correctly: grammar, syntax, spelling… You do it for programs why not for your visitor?

Run tests with willing proofreaders, there’s always bugs you won’t have spotted.

Keep practicing; you didn’t become a code ninja in a single night…

These best practices may seem obvious… But unfortunately they are not always implemented (yes, we all have some bad reading experiences in mind…), so let’s try and use them.

Redis as a protocol

2012-01-27T00:00:00+01:00

HTTP is the king of communication protocols, and it just won the internet war. Everything else is details; I love details.

Distant APIs

It has become almost indisputably common sense that non local services have to expose their APIs as REST APIs. From small private services to large cloud services, everybody speaks HTTP, the new lingua franca. You can debug with curl, handling authentification, compression, content negociation, caching and all other http wonders. But it has a cost, an overhead, and I don't even speak about SOAP here.

However there is a challenger for doing RPC without language restrictions.

Thrift was created by FaceBook for exposing services to different languages. It uses a neutral grammar to generate code for your language. The protocol specifies different communication layers (like TCP), rpc and errors; just like SOAP without XML and HTTP. It's a nice thing for class oriented developers.

You can do similar things with Google's Protobuf, albeit with more work, because only serialization and grammar are specified. There's also Avro, which is an attempt to simplify Thrift while cutting the link with Facebook. And it's more geared towards dynamic languages, Ilya Grigoric explains it better than me.

Minimalism

I wanted to try something distinct from HTTP. Something connected, with a simple message protocol, similar to communications between actors in the actor pattern.

Such a protocol is the memcache protocol. It's used to silently replace a memcache server (see CouchBase), or to expose a simple persistant connection (ElasticSearch).

When implementing a protocol used by many servers, you can use handcrafted and optimized client implementations…

So, if it works with Memcached, why not try Redis? The number of clients is huge, most of them based on hiredis, the official C client. And the protocol is extensible.

You can put a real Redis in your stack and mix Redis' patterns (queue, pubsub, incremental counter, cache…). All that while using a single protocol between application services and Redis services.

Expose your services as a Redis server

I chose nodejs to make some tests. Node is asynchronous and the king of POC; I could have chosen Erlang or EventMachine, but I wanted to see something running quickly.

The server is simple: a TCP server feeding a Redis parser. The parser is a hidden API, but node is not so strict. When a command is complete, a reply event is thrown, and you can handle the reply with the simple types available in Redis.

var redisd = require('redisd');

var server = redisd.createServer(function(command) {
    if (command[0] === 'info') {
        this.encode('redis_version:2.4.5');// I'm a liar
    } else {
        this.singleLine('OK');
    }
});

server.listen(4242, function() {
    console.log('server listening on port 4242');
});

You can test this server with redis-cli and your favorite language API. This project is small, it's just glue between well tested products. But now you can go ahead and build your own, with gevent, eventmachine, erlang … or implementing the MULTI/EXEC patterns…

Simple like Hello 2012

2012-01-26T00:00:00+01:00

If you are interested in how we made this year's new year greeting (which you can find here 2012.af83.com), here is a simplified architectural view:

Basically a simple Sinatra based server, serving the static content. When you submit the form it repeates the message on an irc channel using Cinch. There are two other IRC bots on the same channel, one is on the EEEpc controlling the Fux that Controls the Tux, which makes it speak and move. The other is on the laptop that is connected to the camera, adding the text from the IRC channel to the video which is then encoded and streamed to the Wowza which reencodes it for Flash and HTML5 video.

Sounds complicated?

Well it ain't, basically all of the server side code can be resumed to :

require 'cinch'
require 'sinatra'
require 'eventmachine'

set :public_directory, Proc.new { File.join(root, "public") }

get '/' do
 File.read(File.join('public', 'index.html'))
end

post '/form' do
  $bot.send("#af83-2012", "tux speak " + params[:message])
  $bot.send("#af83-2012", "tux mouth #{params[:message].split.size} close")
  $bot.send("#af83-2012", "tux flippers 2 down")
end

$bot = Cinch::Bot.new do
  configure do |c|
    c.server = "irc.freenode.org"
    c.channels = ["#af83-2012"]
    c.nick     = "TuxCamBot"
  end
end

EM::defer {
  $bot.start
}

99Lime HTML KickStart : test réussi !

2012-01-25T00:00:00+01:00

Après le célèbre Twitter Bootstrap que l'on ne présente plus (voir l’avis de François), 99Lime HTML Kickstart fait son apparition, il s'agit d'un framework html / css / jquery qui permet de produire plus facilement et rapidement le layout de votre site.

Framework assez complet, documentation accessible, il commence déjà à plaire à beaucoup de développeurs et intégrateurs si l'on en croit les tweets récents. Au premier abord je le trouve d’ailleurs plus facile à prendre en main que Twitter Bootstrap.

Simple à installer et à utiliser, il vous réconciliera avec le html / css, on y retrouve tout ce qu'il faut pour démarrer rapidement un projet sans que les maquettes soient finalisées :

Listes
Menu/Navigation vertical gauche ou droite / horizontal avec des effets js pour les sous-menus
Tableaux
Des choix de boutons, avec ou sans couleur, avec ou sans pictos (même si je reste réservée pour les images dans les boutons)
Onglets positionnés à gauche, au centre ou à droite
Fil d'ariane
Plusieurs dispositions en colonnes (taille et nombre)
Différents designs, formats et placement de l'image, sans oublier une galerie d'images
Slideshow
Formulaires

Pour finir, oubliez les différences d'interprétation des navigateurs car le framework est compatible avec tous… enfin mention "dégradé" sur IE6 !

À votre tour : 99LimeHTMLKickStart

Ori Pekelman rajoutera sa Pekelman's Touch :

Autre petit intérêt, la grille proposée est fluide, à la différence de bootstrap orienté largeur fixe.

Par contre quelques bémols assez importants… lime n'as pas du tout été pensé comme bootstrap pour être une mince couche modifiable par la suite. Nulle variable. Pas de Mixins. Ni Less, ni SCSS, ni SASS.. Donc l'utiliser c'est de le forker…

Démarrage rapide mais maintenabilité très basse. D'ailleurs le fait qu'il propose un lien de téléchargement d'archive plutôt qu'un lien vers le dépôt github démontre bien qu'il s'agit d'un projet qui n'est pas vraiment orienté vers les développeurs structurés.

Le JS embarqué est de la même nature, plusieurs librairies ensemble dans le même fichier, et qui tapent en dur sur des sélecteurs comme ul.menu (d'ailleurs voir de nos jours <div id="nav"> et <div id="footer"> ça fait un peu mal, pas très HTML5 tout ça).

Sinon, si pour vous l'intérêt principal c'est la grille fluide, allez voir le très sympatique http://semantic.gs (qui d'ailleurs par la magie de Mixins, peut très bien fonctionner avec bootstrap).

Ajout : il existe maintenant htmlkickstart-rails pour utiliser HTML Kickstart avec l'asset pipeline de Rails.

Autocomplete with tire

2012-01-19T00:00:00+01:00

Full-text databases can do more than full text search. Elastic Search provides a full toolbox for indexing and manipulating text and data. Tire provides a nice and rubyish interface for using this tool.

Autocomplete is one of its basic features. Autocomplete suggests words starting with letters that you have just typed, and refining suggestions as you type.

Iterate and filter

Most databases handle that feature with a filter (with LIKE keyword in SQL, regular expression search with mongoDB). The strategy is simple: iterate on all results and keep only words which match the filter. This is brutal and hurts the hard drive. Elastic Search can do it too, with the prefix query.

With a small index, it plays well. For large indexes it will be more slow and painful.

Look for what you want

Elastic search is an index, iterating over an index is a bit paradoxical. The main feature of an index is finding quickly something and giving back a reference to the complete information. Just like an index in a book: your eyes scan quickly a list of alphabetically sorted words, and you have the page number for reading the information.

It's hard to build an index, but when it's done, it's very fast to find something. Usually, data are not modified very often, there is far more reading than writing, the cost of indexing is cheap when you compare it with the searching speed benefit.

Elastic Search indexes document with tokens extracted from properties. Prefix search is a specific need and is handled with edge ngram, a variant of ngram. Ngram is a group a contiguous letters extracted from a word. Edge ngram is a ngram built from the start or the end of a word.

For example, you are a biologist and want to index the word Heterastridium, with a min size of 3 and max size of 6. Too few letter is not enough deterministic, too many is a waste.

This word Heterastridium is tokenized as:

het
hete
heter
hetera

Like any elastic search query, I can add more criteria, filters or facets.

Tire in action

Edge ngram tokenization is very specific, it can't be used for full search, or even sorting, but one property can be indexed more than one time, and elastic search handles that nicely.

Code example

Boilerplate.

#encoding: utf-8
require 'rubygems'
require 'tire'
require 'json'
require 'active_support/core_ext/object/to_query'
require 'active_support/core_ext/object/to_param'

One analyzer for starting, one for sorting.

conf = {
  settings: {
    analysis: {
      analyzer: {
        my_start: {
          tokenizer: 'whitespace', #I know it's a title, with no ponctuation
          filter: %w{asciifolding lowercase my_edge} #no accent, downcase
        },
        my_sort: {
          tokenizer: 'keyword', #cut nothing, it's just for sorting
          filter: %w{asciifolding lowercase}
        }
      },
      filter: {
        my_edge: {
          type: 'edgeNGram', #1 to 10 letters, from the start
          min_gram: 1,
          max_gram: 10,
          side: 'front'
        }
      }
    }
  },
  mappings: {
    coral: {
      properties: {
        id: {type: 'string', index: 'not_analyzed', include_in_all: false},
        name: { type: 'multi_field', fields: {# this property needs multiple index
          start: {
            type: 'string', analyzer: 'my_start', include_in_all: false
          },
          sort: {
            type: 'string', analyzer: 'my_sort', include_in_all: false
          }
        }
      }
    }
  }
  }
}

Some data : scientific name of corals stolen from Wikipedia.

corals = [
  'Hydractinia echinata',
  'Heterastridium',
  'Hydractinia symbiolongicarpus',
  'Hydrichthys'
]

Feeding an empty index with corals.

Tire.index 'corals' do
  delete
  create conf

  cpt = 0
  import corals.map{ |coral|
    cpt += _posts/2012-01-12-autocomplete-with-tire.md1
    {id: cpt.to_s, name: coral, type: 'coral'}
  }
  refresh
end

Most of tire's job is to provide a complex JSON to elastic search.

Searching and sorting. Which words start with "hydr".

s = Tire.search 'corals' do
  query do
      string 'name.start:hydr'
  end
  sort do
    by :'name.sort', 'asc'
  end
end

s.results.each do |document|
  p document.name
end

The code example prints the list of words in the standard output, quickly and sorted.

Conclusion

Brute force is alway an option, ad hoc tools can do more, with less.

Elastic search provides specialized tools for common needs, use them!