Dev blog af83 | This is the developers blog @ af83

Mongoid tips

2013-04-29T00:00:00+02:00

Ce billet présente quelques astuces sur l'utilisation de mongoid et mongoid_translate.

Les traductions dans mongoid_translate sont des documents « embedded ».

Pour chercher un document avec une traduction :

Tag.where(:'translations.name' => 'Content',
  :'translations.language' => :fr).one

Pour trouver un tag à partir de sa traduction, ou en initialiser un nouveau s'il n'existe pas encore :

t = Tag.find_or_initialize_by(:'translations.name' => content)

On peut ensuite créer la traduction comme ceci :

t.translations.new(language: :fr, name: content)
t.save

Voilà, ça permet aussi de parler du projet « mongoid_translate », une gem développée par af83 pour gérer de la traduction de contenus avec mongoid.

Dispositif interactif pour la biennale de Saint-Étienne

2013-04-16T00:00:00+02:00

Nous avons eu récemment l'opportunité de travailler avec EDF sur un dispositif interactif pour la biennale de Saint Etienne. Ce dispositif devait offrir aux visiteurs la possibilité de construire et tester librement des systèmes électriques à l'échelle de la France, via une interface tangible conjuguant des écrans et la manipulation d'objets "communicants".

La technologie de détection de ces objets a été créée par la start-up ePawn. Nous sommes intervenus sur le design et le développement de l'application exploitant les déplacement des objets pour générer des informations et des scénarios.

Petit retour sur le déroulement et les principaux enjeux de ce projet.

Le déroulement du projet

Nous avons travaillé en méthode agile (SCRUM). La mise en place de l'API pour récupérer les informations des objets, le design et le développement du workflow, des mécanismes d'interaction, l'intégration des données et algorithmes de production d'énergie, le design graphique comme l'intégration ont été menés en parallèle, à travers les différents cycles du projet.

Comme l'interface est pilotée par la manipulation des objets tangibles, nous avons mis en place un protocole nous permettant de simuler facilement les déplacements des objets, et de tester l'interface en conséquence. Nous avons ainsi pu constamment travailler par tests et itérations.

Enfin, le designer a assumé le rôle du scrum master, ce qui a permis d'impliquer le design à toutes les étapes du projet, y compris de développement. Cela a contribué à garantir la cohérence du projet en termes d'usages. Des ateliers avec le client ont également été menés très régulièrement.

La communication en temps réel : un enjeu crucial

La manipulation des objets par le visiteur produisent des informations. Ces information déclenchent des actions et évènements dans l'interface, et sont associées à des représentations graphiques sur les deux écrans. Un des principaux enjeux du projet a été de permettre que les objets, les deux écrans et les représentations graphiques communiquent constamment en temps réel, afin de garantir la fluidité et les performances de l'interface.

Pour cela :

Les deux écrans sont en fait deux fenêtres de navigateur (Chrome)
Un serveur en nodejs sert à synchroniser les deux écrans en leur envoyant des événements en EventSource
La position des pions est récupérée via un daemon en C utilisant la technologie ePawn, puis transmise au serveur nodejs pour qu'il puisse traiter les déplacements.

Des modalités d'interaction inédites

Le caractère hybride de l'interface (objets physiques / interfaces numériques) a requis de mettre en place des outils de prototypage spécifiques. Nous avons d'abord modélisé l'interface et les objets en papier pour tester et préciser le workflow. Puis nous avons réalisé une maquette échelle 1 pour mieux percevoir les encombrements, définir les éléments graphiques et ajuster leur taille en conséquence.

Par ailleurs, le fait de manipuler des objets physiques pour interagir avec des informations numériques ouvre des perspectives d'usages et d'interfaces inédites. Nous avons tenté de sortir du langage informatique traditionnel, pour proposer des représentations et interactions ayant du sens par rapport aux objets manipulés.

Légende : représentation des différents usages ayant eu lieu dans la journée

Légende : étape de configuration de la saison et des sources d'énergie

Des animations full-CSS

Pour offrir une expérience d'usage incitant à expérimenter le dispositif, nous avons créé un univers graphique et des animations riches, depuis les datavisualisations affichées autour des objets, jusqu'à la simulation du déroulement d'une journée.

Pour obtenir cette richesse graphique avec des technologies purement web, nous avons utilisé :

D3 et JS pour les animations en temps réel
Full CSS3 pour les autres animations

Pour conclure

Le fait d'utiliser des technologies web pour ce type de dispositif permet d'obtenir un résultat flexible, qui pourra facilement évoluer par la suite… Mais cela a aussi amené de nombreux challenges tant pour les développeurs back et front que les designers.

Ces challenges, ainsi que la très forte implication du client dans le projet ont enthousiasmé toute l'équipe qui s'est énormément investie pendant les deux mois et demi du projet. Nous sommes très heureux de voir à présent le dispositif installé et utilisé avec succès à la biennale de design !

L'équipe du projet :

Chez af83 : Alice, Arnaud, Bruno, Gilles, Mathilde, Maxim, Victor
Sur la partie design graphique : Adrien Bridet

Release: Sponges, daemons in a pool

2013-04-04T00:00:00+02:00

When I build workers, I want them to be like an army of little spongebobs, always on the edge and ready to work. sponges helps you create this army of sponges, control them, and well…kill them at will too. Making them eager to work is now your job. :)

Basically, sponges is a ruby supervisor that forks processes and controls their execution, termination and forks a new process each time a process disappears from the processes pool.

For example, the following command will start a supervision daemon and 8 processes of "a_worker".

ruby a_worker.rb start -d -s 8

If you kill the supervisor, it will cleanly terminate the child processes.

Installation

Ruby 1.9.3 (or superior).

Install it with rubygems:

gem install sponges

With bundler, add it to your Gemfile:

gem "sponges"

Usage

In a file called example.rb:

# The worker class is the one you want to daemonize.
#
require 'sponges'

class Worker
  def initialize
    # Trap the HUP signal, set a boolean to true.
    trap(:HUP) {
      Sponges.logger.info "HUP signal trapped, clean stop."
      @hup = true
    }
  end

  def run
    Sponges.logger.info Process.pid
    if @hup # is true, we need to shutdown this worker
      Sponges.logger.info "HUP signal trapped, shutdown..."
      exit 0 # everything's fine, we can exit
    else # this worker can continue its work
      sleep rand(20)
      run
    end
  end
end

Sponges.configure do |config|
  config.logger            = MyCustomLogger.new   # optionnal
  config.size              = 3                    # optionnal, default to cpu's size
  config.daemonize         = true                 # optionnal, default to false
  config.port              = 5032                 # optionnal, default to 5032
  config.after_fork do
    puts "Execute code when a child process is created"
  end
  config.on_chld do
    puts "Execute code when a child process is killed"
end

# Register a pool named "worker_name".
#
Sponges.start "worker_name" do
  Worker.new({some: args}).run
end

See the help message :

ruby example.rb

Start workers :

ruby example.rb start

Start workers and daemonize them:

ruby example.rb start -d

Start 8 instances of the worker and daemonize them:

ruby example.rb start -d -s 8 # By default, size equals cpu core's size.

Restart gracefully 4 instances of the worker, with a timeout of 3 seconds and daemonize them:

ruby example.rb restart -g -s 4 -t 3

Stop workers with a QUIT signal :

ruby example.rb stop

Stop workers with a KILL signal :

ruby example.rb kill

Stop workers with a HUP signal :

ruby example.rb stop -g -t 5

In this case, you will have to trap the HUP signal, and handle a clean stop from each worker. The point is to wait for a task to be done before quitting. A timeout can be specified with the -t option. When this timeout is hit, the process will be automatically killed.

Increment worker's pool size :

ruby example.rb increment # will add a worker to the pool.

Decrement worker's pool size :

ruby example.rb decrement # will remove a worker to the pool.

Http supervision

sponges provides an http interface to supervise pool's activity, and to expose pids. Http supervision can be enabled in configuration:

Sponges.configure do |config|
  config.port            = 3333
end

By default, sponges listens on port 5032, and responds in json. Here is an example of response:

{
  "supervisor":{
    "pid":11537,
    "pctcpu":0.0,
    "pctmem":0.22,
    "created_at":"2013-03-05 15:21:04 +0100"
  },
  "children":[
    {
      "pid":11540,
      "pctcpu":0.0,
      "pctmem":0.21,
      "created_at":"2013-03-05 15:21:04 +0100"
    },
    {
      "pid":11543,
      "pctcpu":0.0,
      "pctmem":0.21,
      "created_at":"2013-03-05 15:21:04 +0100"
    },
    {
      "pid":11546,
      "pctcpu":0.0,
      "pctmem":0.21,
      "created_at":"2013-03-05 15:21:04 +0100"
    },
    {
      "pid":11549,
      "pctcpu":0.0,
      "pctmem":0.21,
      "created_at":"2013-03-05 15:21:04 +0100"
    }
  ]
}

Patterns

We use sponges on several of our projets, and we can see two different patterns of use for sponges.

The classic way

A worker build upon Redis, Beanstalkd, or anything capable of blocking on a queue. This worker waits for a job, receive a job, process the job, and waits for a new job. Simple and straightforward.

This task must use pull/push socket, and not pub/sub. When a pool of workers is starting, we do not want to have several workers receiving the same task.

The brutal way

The brutal way looks like the classic way, except it does not wait for a new job, it exits.

Yes, exactly, it exits. By doing so, the supervisor will catch a signal for an exiting child, and fork a new process. This process takes the turn on the queue, and wait for a job.

Why this pattern ? Because of memory management. By exiting, the memory is completely freed by the kernel. We used this pattern in a worker manipulating some huge xml files (around 1 go) which happens to leak memory quite fast.

However, this pattern is slower, since it has to require everything on each job.

Unix

Internally, sponges strongly relies on Unix, using fork, signals and pipe.

fork is used to create one or several worker process.

Signals are used to delegate commands from the supervisor to each process. By nature, signals are asynchronous and unidirectional. Not knowing when a signal occurs is not a problem, but not knowing when Ruby will run a signal handler could be one. The tricky case: receiving a signal while doing some work on another signal handler.

We solved these problems with a pipe. When a signal occurs, only one action is performed: writing this signal to a pipe. A thread dedicated to signals handlers reads this pipe and performs handler one at the time. This solves two problems:

by enforcing signals to be synchronous, we erase most of weird edge cases we have seen in the firsts versions of Sponges.
Ruby 2.0 compatibility. From 2.0, Ruby does not allow to use a mutex in a signal handler. So something like writing to a logger could break. Writing to a pipe, on the other hand, does not break.

One last word

Sponges would not have been the same without Jesse Storimer and his awesome book about Unix.

Document all the things

2013-03-18T00:00:00+01:00

We've just released documentator. documentator is like capistrano-af83, but for documentation. The idea is the same: not to redo the same thing over and over again on each project.

documentator has one primary goal: having better docs on our projects.

Installation

The rubygems way:

Or with bundler, add it to your Gemfile:

group :development do
  gem "documentator"
end

Usage

Commands should be used from the root directory of the current project.

Bootstrap

bootstrap provides a minimal set of documentation files. Those are empty, and they must be written for each project. The content is specific to each project:

What's the architecture? (providing a ditaa schema will earn you some extra karma points)
Dependencies?
Environnements?

As a treat, bootstrap generates a Gemfile in project/doc which includes Guide'em up. Guide'em up can be used to preview markdown file in a browser.

bundle exec documentator bootstrap

Importing templates

import provides templates for common documentation that should be the same from one project to another. Installing ElasticSearch is basically always the same. If there are projet specific particularities, you can always add them here.

Since version 0.1.0, documentator supports internationalization.

bundle exec documentator list
bundle exec documentator list fr
bundle exec documentator list en

bundle exec documentator import fr elasticsearch

Contribution

YES. We want contributions. Pull-requests are welcome !

Adding a bootstrap file is done by adding a file to lib/documentator/bootstrap.
Adding a templates file is done by adding a file to lib/documentator/templates.

Why you should consider Beanstalkd

2013-03-13T00:00:00+01:00

Processing in background IO bound or cpu bound tasks is now a common practice in most web applications. There's plenty of software to help build background jobs, some based on Redis, some based on a specific language implementation with threads, some based on a messaging system, and there's Beanstalkd.

Background

In the past few months, I had the opportunity to work on a big scale backend project. The essence of this project is to take as input various, in typology and size, xml files. Complex validations and transformations are applied on this data, caches are prepared, the extracted data is stored and indexed, and so on. Each of these tasks is done by a well identified worker that can be written in ruby, php or perl.

This legacy system was built upon mysql, some polling and a big start launched every single day.

One of our many missions was to make it resilient to stopping / restarting, to allow input at any given moment, and eliminate any notion of beginning or end. But… without changing everything in either the inputs or outputs of the system. And… we get bonus points for a priority based system.

Oh, one last detail, this system needs to be distributed across dozens of servers. And, as you maybe already know, distributed systems are not easy beasts.

Messaging

From the beginning, we chose to inverse the approach: no more polling. Workers do not ask for a job, they wait that another brick gives them one. We then needed a system that organizes, prioritizes and distributes jobs, hence a messaging system. We considered various options like RabbitMQ, ØMQ and Beanstalkd.

Those options could look surprising, since one is a "messaging server", another is a "socket library", and the last one is a "work queue". And yet, we had, at some extend, a proof of concept running of each of those solutions.

We ruled out RabbitMQ because it does not provide any easy and reliable priority management.

We ruled out ØMQ because it was not "enterprise-ready" enough, and as a framework, it demands way more effort than a "server as a binary that just works".

But, ØMQ, being such a beauty, will be the topic of an upcoming blog post.

So, why Beanstalkd ?

Basically, we needed to distribute jobs across a closed network, to prioritize them, and consume them. Well, that's exactly what Beanstalkd provides.

Beanstalkd gives the possibility to organize jobs in tubes, each tube corresponding to a job type. Tubes are lazily created. A client can listen to several Beanstalkd's tubes.

A producer can put jobs in a tube, let's say a json representation, for example. put accepts various options like ttr, pri or delay. and pri allows to define a priority on a job. This was a killer feature for our use case.

A consumer can reserve a job: if no job is available, Beanstalkd will wait until a job becomes available. The client has a limited amount of time to process this job. When the ttr (time to run) time out, Beanstalkd will push back the job in queue. A consumer can touch to push back a TTR.

When a job is successfully processed, a consumer can delete the job from the tube. In the case of failure, the consumer can bury the job. This job will not be pushed back to the tube, but will be available for further inspection.

A consumer can release a job, Beanstalkd will push this job back in the tube, and make it available for another client. release is commonly used with the delay option. This option tells Beanstalkd to push back this job in the tube, but with a delay.

Beanstalkd clients can be found in most common languages, a web interface can be useful for debugging.

Overall

Beanstalkd was really the right tool for the job: full-featured, lightweight, language agnostic, and easy to administrate.

It is so easy to work with, we kind of forgot Beanstalkd is at the center of this system.

If you are interested in Beanstalkd, and you should be, the best read so far is the protocol description. It is an easy read and, by definition, an in-depth guide of Beanstalkd's features. Proving, Beanstalkd is a really well designed piece of software.

Ajouter un job jenkins en ligne de commande

2013-03-11T00:00:00+01:00

Nous avons au fil des projets créé une sorte de template de job jenkins.

Le problème est que l'on utilise la fonction « Copier un Job existant » de jenkins et on doit faire des rechercher/remplacer.

Ce n'est pas très pratique via l'interface web de jenkins car certaines options sont cachées, et donc, on finit par en oublier.

On peut récupérer la config xml pour un job via un projet existant, par exemple :

cp ~/.hudson/jobs/NOM_DU_JOB/config.xml jenkins-project-template.xml

Puis éditer le fichier jenkins-project-template.xml pour avoir un fichier interprétable par ERB.

Un exemple avec l'URL du projet :

<projectUrl>https://github.com/AF83/<%= PROJECT %>/</projectUrl>

Une fois toutes les variables mises en place, on peut utiliser le template pour générer un job avec :

export PROJECT=sponges

ruby -rerb -e "PROJECT = ENV['PROJECT']
e = ERB.new(File.read('jenkins-project-template.xml'))
puts e.result" > $PROJECT.hudson.config.xml

curl -H "Content-Type: text/xml" -s --data "@$PROJECT.hudson.config.xml" \
"http://localhost:8080/createItem?name=$PROJECT"

Scruter ses processus avec strace

2013-03-07T00:00:00+01:00

strace est un outil, utilisable en ligne de commande, qui affiche les appels systèmes effectués par un processus et ses enfants. Ces appels systèmes sont le seul contact du processus avec l'extérieur : pas de lecture de fichier, de réseau ou d'affichage sans passer par des appels au noyau. L'affichage de ces appels permet de débugger et d'étudier le comportement du processus en laissant de coté la logique du code pour s'attacher uniquement à ses interactions.

strace s'utilise simplement en lui passant une commande à exécuter :

$ strace ls
[...]
open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, /* 5 entries */, 32768)     = 144
getdents(3, /* 0 entries */, 32768)     = 0
close(3)                                = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 4), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1119e93000
write(1, "brownies  cookies  cupcakes\n", 28) = 28
close(1)                                = 0
munmap(0x7f1119e93000, 4096)            = 0
close                                = 0
exit_group(0)                           = ?

Cet exemple permet de décortiquer le fonctionnement de la commande ls. On peut y voir l'ouverture du répertoire . avec open, son parcours avec getdents ainsi que l'écriture du résultat sur la sortie standard avec write. Ces appels système disposent généralement d'une page de man qui décrit leur différents paramètres et la valeur renvoyée (section 2 des pages de man).

Ces appels peuvent être séparés en plusieurs catégories :

les appels dédiés à la communication avec l'extérieur : il s'agit notamment des appels open, read, write, close et par extension tous les appels qui manipulent des descripteurs de fichier. Dans l'exemple précédent, la fonction open qui ouvre le répertoire . renvoie le descripteur de fichier 3, ce descripteur sera utilisé par getdents pour récupérer le contenu du répertoire avant d'être fermé par close. D'autres appels renvoient des descripteurs, notamment accept qui ouvre un descripteur pour la communication avec un client (généralement en TCP) ou connect pour la communication avec un serveur ;
les appels dédiés à la gestion de la mémoire : mmap, munmap, brk et sbrk permettent d'allouer et de libérer des portions de la mémoire. L'exemple précédent montre un appel à mmap pour allouer un buffer de 4096 octets, ce buffer sera utilisé pour copier la sortie (le nom des fichiers) avant l'écriture sur la sortie standard puis sera désalloué avec munmap. Notons que mmap est aussi utilisé pour mapper des fichiers en mémoire.

D'autres appels, qui ne sont pas présents dans l'exemple de ls, sont aussi très courants :

les multiplexeurs : généralement poll, select, epoll_wait ou kqueue. Ces appels servent généralement de point central à un processus, ils permettent de gérer les différents canaux de communication d'un processus en regroupant l'attente des évènements en un seul appel. Ces appels sont bloquants et ne retournent que lorsqu'un évènement arrive sur un descripteur de fichier ou que leur timeout est atteint ;
les appels dédiés au temps : souvent gettimeofday ou clock_gettime qui permettent de retourner différentes interprétation du temps ;
les appels dédiés aux threads : généralement tous ceux qui commencent par pthread_ ;
les appels dédiés aux signaux : kill et signal sont les plus connus mais Posix en compte un certain nombre.

Quelques explications sur les options de strace

Quelques options de strace méritent un peu plus d'attention :

-p : permet de s'attacher à un processus qui est déjà en train de s'exécuter, en utilisant son pid. Notons que comme strace utilise l'API ptrace il n'est pas possible de tracer plus d'une fois le même processus ou de tracer un processus qui se trace lui même ;
-f : permet de suivre les forks d'un processus en affichant à la fois les appels du parents et des enfants ;
-o : enregistrer la sortie dans un fichier ;
-c : afficher des statistiques sur le temps passé et le nombre d'appels.

Identifier les problèmes

Les fuites de mémoires

Deux comportements peuvent caractériser une fuite de mémoire :

de nombreux appels à brk avec un paramètre qui augmente constamment ;
de nombreux appels à mmap sans appel à munmap.

Le programme suivant génère une fuite de mémoire :

int main() {
  for (;;)
    malloc(4096);
}

Le résultat avec strace :

[...]
brk(0)                                  = 0x1f7e000
brk(0x1fa0000)                          = 0x1fa0000
brk(0x1fc1000)                          = 0x1fc1000
brk(0x1fe2000)                          = 0x1fe2000
[...]
brk(0x1fd7c000)                         = 0x1fd7c000
brk(0x1fd9d000)                         = 0x1fd9d000
brk(0x1fdbe000)                         = 0x1fdbe000
[...]

Les fuites de descripteurs de fichier

Les descripteurs de fichier servent d'identifiants pour les fichiers, les connexions, les pipes (dont l'entrée et la sortie standard) et pour un certain nombre d'autres interfaces. Tout comme la mémoire, ceux-ci doivent être libérés pour ne pas atteindre les limites imposés par le système.

Les descripteurs de fichier sont des entiers qui se suivent, si l'un d'eux est libéré il sera immédiatement recyclé pour servir d'identifiant à une autre ressource. Il est donc assez facile d'identifier les fuites en observant le numéro des descripteurs : si ceux-ci sont de plus en plus élevés sans raison apparente c'est qu'ils ne sont pas fermés correctement.

Le programme suivant ouvre tous les fichiers d'un répertoire sans jamais les fermer :

int main() {
  DIR * dir;
  struct dirent * entry;

  dir = opendir (".");
  while (entry = readdir (dir))
    open (entry->d_name, O_RDONLY);
}

Le résultat avec strace :

[...]
open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, /* 128 entries */, 32768)   = 4240
open(".dbus", O_RDONLY)                 = 4
open(".cache", O_RDONLY)                = 5
open(".gvfs", O_RDONLY)                 = 6
[...]
open(".profile", O_RDONLY)              = 431
open(".bash_logout", O_RDONLY)          = 432
open(".gegl-0.0", O_RDONLY)             = 433
[...]

Autres comportements anormaux

Un processus qui fait un minimum d'entrée/sorties dans le temps utilisera, presque toujours, un multiplexeur (généralement poll, select, epoll_wait ou kqueue) qui lui permettra de suivre simultanément tous les évènements susceptibles de le réveiller, tout en bloquant sans consommer de CPU quand aucune tâche n'est en cours.

Un serveur HTTP en bonne santé fournira plus ou moins la trace suivante. À la réception d'une requête, la fonction epoll_wait retourne, le serveur traite la demande puis bloque à nouveau dans epoll_wait en attendant une nouvelle requête.

$ strace -p [pid]
epoll_wait(16, }, 512, 4294967295) = 1
accept(13, {sa_family=AF_INET, sin_port=htons(39824),
           sin_addr=inet_addr("127.0.0.1")}, [16]) = 3
recvfrom(3, "GET / HTTP/1.1\r\nHost: localhost\r"..., 1024, 0, NULL, NULL) = 376
write(3, "HTTP/1.1 404 Not Found\r\nServer: "..., 387) = 387
close(3)
epoll_wait(16,

Imaginons maintenant que ce serveur HTTP ne réponde plus malgré le fait que son processus soit toujours présent. On peut diagnostiquer le problème en s'attachant directement au processus :

si il n'y a aucun retour de strace, le serveur est très certainement bloqué dans une boucle entièrement logique (sans appels systèmes) ;
si le serveur est bloqué sur un autre appel que le multiplexeur, il peut s'agir d'un I/O sur une ressource particulièrement lente, dans le cas d'appels à read, write ou leurs dérivés, ou d'un deadlock, notamment si le serveur bloque sur un appel à pthread_mutex_lock ;
si le serveur passe toujours par son multiplexeur mais retourne directement, il s'agit généralement de la notification d'un évènement demandant une lecture ou une écriture qui ne serait pas ensuite exécutée par le serveur ;
si le serveur reste bloqué sur le multiplexeur malgré les requêtes qui lui sont envoyées : il se peut que la socket du serveur soit fermée ou qu'elle ne soit pas en écoute sur le port ou l'interface réseau attendu.

Beyond strace, d'autres outils utiles

lsof permet de lister toutes les ressources ouvertes par les processus, il est très utile pour savoir à quoi correspond un descripteur de fichier affiché dans la sortie de strace ;
valgrind et toute sa suite d'outils permettent d'observer la consommation mémoire, les problèmes de multi-threading, l'accès au cache et comportement anormaux d'un processus ;
ltrace est le petit frère de strace, permettant de suivre non pas les appels systèmes mais les appels à des bibliothèques dynamiques.

Load testing with Siege

2013-02-28T00:00:00+01:00

This post will try to explain how to perform a load test of your web application without pain.

To achieve this, we'll use Siege, which is a GPL software written by Jeff Fulmer.

Its goal is to perform stress and regression tests by defining a list of urls to be stressed.

Defining scenarios

Urls are defined in a simple .txt file, each line is an url that Siege will hit during each scenario.

Siege urls are defined by:

the url
the HTTP verb
the query string

Let's see some examples.

Hitting the home page of http://example.com:

http://example.com

To simulate a login request with login foo and password bar:

http://example.com/users/sign_in POST login=foo&password=bar

Variables can be used, to prevent domain name repetition for example:

HOST=http://example.com
$(HOST)/
$(HOST)/page1

Authenticated scenarios

Most applications can't be stressed completely without user authentication. Siege allow to define urls that will be executed before each scenario.

These urls have the same format as url in scenario, but are defines in the login URL section of Siege config file (siegerc).

You can generate this file by running siege.config.

Example :

login-url = http://example.com/users/sign_in POST login=user1&password=bar1
login-url = http://example.com/users/sign_in POST login=user2&password=bar2

Given this configuration, Siege will execute one of these requests before launching a new scenario.

Of course, if your application is protected against CSRF attacks, you must disable these protections during the test.

In a Rails application, you just need to remove the protect_from_forgery in your controllers.

Start !

Now you can start mistreating your application ;)

There are many options you can use, man siege is your friend, the most important:

-C: path of your siegerc file
-f: path of your urls file
-c: concurrency
-t: test duration
-v: verbose, this will output hits during test.

The following command will start the test using:

siege -C .siege/siegerc -f .siege/urls.txt -c 100 -t 1H

.siege/siegerc as config file
.siege/url.txt as urls file
a concurrency of 100 users
a duration of 1 hour for the test

Report

At the end of the test, Siege will output some informations:

number of transactions performed
elapsed time
amount of data transferred
average response time of transactions
average number of transaction per second
average amount of data transferred per second
average number of simultaneous connections
number of transaction where status code is 200
number of successful transactions
number of failed transactions.

It also writes a log file with a summary of the test results in .siege/siege.log.

Troubleshooting

There is a known issue with Siege and cookies without expiration, see this ticket for more informations.

In a rails application, you can simply add an expiration to bypass this issue, like this in config/initializers/session_store.rb:

MyApp::Application.config.session_store :cookie_store, key: '_my_app_session', expire_after: 1.year

Persisting changes - chrome dev tools

2013-02-25T00:00:00+01:00

Pourquoi ne pas utiliser chrome dev tools pour faire de la css ?

Ne connaît-on pas trop bien le workflow qui suit ?

Je rajoute des styles dans mon inspecteur chrome
J'arrive à mon objectif
J'ouvre mon éditeur de texte préféré
J'essaye de me souvenir des changements que je viens de rentrer dans mon inspecteur afin de les rapporter dans ma feuille de style définitive
Je pense avoir terminé et refresh mon navigateur pour voir le résultat
Horreur ! Le résultat n'est pas celui que j'avais précédemment et en plus je viens de perdre toutes mes modifications css
Énervé, je tente de retrouver mon objectif
Je retourne à l'étape 3 et en fonction de la santé de ma mémoire, je peux parcourir les étapes 3/ à 8/ une fois, ou bien un nombre de fois qui tend vers l'infini…

Trêve de plaisanteries, je pense que nous nous sommes tous plus ou moins reconnus dans ce workflow peu glorieux.

Heureusement, il est possible grâce aux chrome dev tools de pallier ce problème : Les "Persisting Changes".

Pour faire joujou, vous aurez besoin d'une version dev de chrome.

Revenons à la fin de l'étape 2 de notre workflow et continuons :

En exemple j'ai rajouté un text-align: left et un position: absolute sur .page.

Il est possible de cliquer sur la feuille de style afin qu'elle s'ouvre dans l'onglet "Sources" (voir ci-dessous)

style.css à été modifié, les modifications sont visibles.

Avec un clic droit sur le fichier style.css, il est également possible de sélectionner "local modifications" (voir ci-dessous)

Une timeline apparaît en bas de l'inspecteur dans laquelle les modifications ont été versionnées ce qui permet de choisir ou revenir à l'état attendu. Vous pouvez visualiser l'historique complet de vos étapes de développement. (voir ci-dessous)

En enregistrant style.css dans un repo git (voir ci-dessous) il est possible de faire un git diff pour vous faire une idée des changements apportés. Tant que l'inspecteur est ouvert, le fichier est actualisé dès lors qu'une révision est appliquée.

Dans un prochain post, nous pourrons nous pencher sur l'utilisation de cette technique dans le cadre d'un projet SASS ou LESS.

Pour plus d'informations :

https://developers.google.com/chrome-developer-tools/docs/elements-styles#persist
http://paulirish.com/2011/a-re-introduction-to-the-chrome-developer-tools/ ce post date de 2011 mais reste très intéressant

Ruby 2.0 : Keyword arguments

2013-02-18T00:00:00+01:00

Here's the long awaited last post in the "Ruby 2.0 feature's tour" series. With a release date still fixed to the 24th of February, it was about time.

This post's topic will be about "Keyword arguments". As you can see, Keyword arguments is not really a new feature invented by the Ruby designers, but rather an addition that has been available for years in others languages..

Principle

Keyword arguments gives the possibility to define arguments in a flexible way. The common practice is to use Hash to pass several arguments in any order.

def devblog(title, options = {})
  puts title, options[:tags], options.fetch(:layout, "post")
end

devblog "Ruby 2.0 : Keyword arguments", tags: ['ruby']
# => "Ruby 2.0 : Keyword arguments"
# => ['ruby']
# => "post"

The same feature could be achieved by using Keyword arguments:

def devblog(title, layout: "post", tags: [])
  puts title, tags, layout
end

devblog "Ruby 2.0 : Keyword arguments", tags: ['ruby']
# => "Ruby 2.0 : Keyword arguments"
# => ['ruby']
# => "post"

No extra fetch for default values, and arguments available as local variable.

In the above example, title is not specified as a Keyword argument to mark this argument as mandatory.

Well, it could be done using Keyword arguments but it's kind of weird.

def devblog(title: raise(ArgumentError), layout: "post", tags: [])
  puts title, tags, layout
end

devblog "Ruby 2.0 : Keyword arguments", tags: ['ruby']
# => "Ruby 2.0 : Keyword arguments"
# => ['ruby']
# => "post"

devblog tags: ['ruby']
# => ArgumentError (ArgumentError)`

Real world use case

Let's now have a look at the select method from Rails's ActionView::Helpers::FormOptionsHelper. This method takes 5 arguments, including 2 hashes. The first hash relates to generic options about the select (like, does it include a blank option), and another one about html's options (like class, id and so on).

So, it can lead to something like this where we want to add a css class to the select element:

select("post", "person_id", collection, {}, {class: "selectable"})

How many Rails' developers have wondered about the order of those 2 hashes?

It could be a common hash, with a key for options, and another one for html_options.

select("post", "person_id", collection, html_options: {class: "selectable"})
options: {include_blank: true }})

That would be nicer, but this will lead to more complexity in setting default values on options and html_options.

By using Keyword arguments, this would look like:

select("post", "person_id", collection, html_options: {class: "selectable"})
options: {include_blank: true }})

Yes, that would look exactly like the previous example.

The main difference would be on the implementation side.

Usage

module Helpers
  # Just here to allow to call Helpers.select directly. For the sake of the
  # example.
  module_function

  def select(object, method, choices, options = {}, html_options = {})
    options = {include_blank: true}.merge(options)
    [options, html_options]
  end

  def select_one_hash(object, method, choices, options = {})
    options[:options] = {
      include_blank: true,
    }.merge(options.fetch(:options, {}))
    [options[:options], options[:html_options]]
  end

  def select_keyword(object, method, choices, options: {}, html_options: {})
    options = {include_blank: true}.merge(options)
    [options, html_options]
  end
end

This module provides 3 versions of the select method, which returns just the options with the defaults.

Helpers#select takes two options hashes
Helpers#select_one_hash takes one nested hash
Helpers#select_keyword uses Keyword arguments

The only difference between Helpers#select and Helpers#select_keyword can be found in the method declaration where the arguments are declared with a : instead of = for the named argument.

Helpers#select_one_hash has a more complex implementation due to the nested hash.

collection = [["name", 23]] # Choises provided to the select method

puts Helpers.select("post", "person_id", collection, {}, {class: "selectable"})
# => {:include_blank=>true}
# => {:class=>"selectable"}

puts Helpers.select("post", "person_id", collection,
                    {include_blank: false},
                    {class: "selectable"})
# => {:include_blank=>false}
# => {:class=>"selectable"}

puts Helpers.select_one_hash("post", "person_id", collection,
                             html_options: {class: "selectable"})
# => {:include_blank=>true}
# => {:class=>"selectable"}

puts Helpers.select_one_hash("post", "person_id", collection,
                             {html_options: {class: "selectable"},
                             options: {include_blank: false}})
# => {:include_blank=>false}
# => {:class=>"selectable"}

puts Helpers.select_keyword("post", "person_id", collection,
                            html_options: {class: "selectable"})
# => {:include_blank=>true}
# => {:class=>"selectable"}

puts Helpers.select_keyword("post", "person_id", collection,
                            html_options: {class: "selectable"},
                            options: {include_blank: false})
# => {:include_blank=>false}
# => {:class=>"selectable"}

This feature will be available in Ruby 2.0 in less than one month, and worth to be looked at!

And this post closes the Ruby 2.0 preview series.

Git commit message

2013-02-11T00:00:00+01:00

git commit -m 'Devblog: Importance des messages de commit'

Les messages de commit sont importants pour la compréhension du patch et pour cibler/intéresser un code-reviewer.

Si vous voulez aussi que votre patch soit accepté par un projet, il est souvent apprécié que votre message soit cohérent et explique votre modification. Ceci aide le travail de l'upstream et augmente les chances qu'il soit intégré.

Un bon moyen de montrer le sérieux de l'auteur est de signer le message par l'option -S. Vous pouvez lire cet article pour plus d'informations dessus.

Les conventions de formatage viennent de l'utilisation des emails pour envoyer un patch pour le kernel, avec la commande git format-patch.

La première ligne doit avoir moins de 50 caractères (c'est le sujet du mail).

Avec pour format d'exemple :

Sujet: Courte description des changements de ce patch (que fait ce patch ?)

Une description si nécessaire plus détaillée du pourquoi, problème rencontré...
Comme pour les emails, la description ne devrait pas dépasser 80 caractères.

On peut mettre le ticket ou numéro de ticket sur une autre ligne.

Si le commit a été relu ou fait par plusieurs développeurs, il y a le mot clef
`Signed-off-by:` (`--signoff`). Ou encore `Reported-by:` pour les bugs reportés.

Linus parle justement de ces mots clef sur github.

N'hésitez pas, non plus, à consulter des projets avec des messages de commit bien faits :

Release de Koalab, outil de collaboration en ligne

2013-02-04T00:00:00+01:00

Koalab est une plateforme de board en ligne, et un projet initié pendant la codeweek d'af83 par une équipe rassemblant des aviateurs de (presque) tous les pôles : développeurs, gestion de projets, user experience, commercial/communication.

Petit retour sur la genèse et les premiers pas du projet…

Pourquoi un board en ligne ?

Chez af83, nous menons la majeure partie des projets en mode agile. Nous faisons également régulièrement des brainstormings, ateliers, etc. en interne comme avec des clients et partenaires. Nous sommes donc familiers avec les boards, Scrum ou autres.

Cependant les supports physiques ont montré leurs limites : le partage à distance (télétravail, clients en confcall,…) est compliqué ; certains projets sont confidentiels et avoir à retourner le board quand des personnes externes sont de passage - ce qui est plus que fréquent - est contraignant ; la quantité de murs libres (et de planches support) est limitée ; il peut y avoir trop d'informations pour que cela tienne sur un board ; etc.

Les partis pris

Il existe déjà pas mal de solutions en ligne : Trello (que nous utilisons beaucoup en interne), des boards collaboratifs comme mural.ly, stixy… Cependant ces outils ne répondaient pas toujours à nos besoins, soit parce qu'ils faisaient trop de choses, soit parce qu'ils avaient des contraintes de "forme" trop grandes. Et puis, avouons-le, nous aimons bien faire nos outils ;)

Donc nous avons décidé de profiter de la "codeweek" annuelle pour développer Koalab, avec les principes directeurs suivants :

simplicité d'usage
liberté la plus grande possible
synchronisation temps réel
multi devices et plateformes
et bien sûr open-source parce que c'est ce que nous aimons…

La première version

Elle a été développée en mode lean : première étape le concept, décliné en wishlist, qui a été triée rapidement par fonctionnalités clés, futures et "rêvées". Deuxième étape, Mathilde et Marie ont travaillé sur l'UX d'un board et une créa "minimale" pendant que Jérôme, Bruno et Pierre ont implémenté les toutes premières features.

Après les premiers tests techniques et utilisateurs, le premier jet est modifié et nous attaquons en parallèle la recherche d'un nom et d'un premier logo… Enfin, une home page listant les boards existants et permettant de créer de nouveaux boards est ajoutée.

À la fin de ces quelques jours, Koalab permet de créer des boards, lignes et post-its et d'éditer et déplacer des post-its sous (presque…) tous les bons navigateurs.

Itérations

Nous avons profité du temps réservé aux ateliers hebdomadaires, et Bruno de ses nuits, pour faire :

du bugfix et l'implémentation de features non réalisées pendant la code week
des tests, des tests et encore des tests
de la compatibilité tablettes
du travail UX (nouvelles fonctionnalités, modifications de comportement)
une "vraie" créa (merci Élodie pour le graphisme et Maxim pour l'intégration).

Le résultat

Comme pour tout projet agile, certaines choses prévues au départ ont été abandonnées ou repoussées, d'autres ont été ajoutées en cours de développement (ou supprimées après mise en ligne…), mais nous sommes fiers de cette première version publique.

Bien entendu, nous mettrons en production des améliorations et nouvelles fonctionnalités régulièrement, nous n'avons pas épuisé la to-do list…

Et vous, votre avis sur Koalab ?

PS : Pour les curieux, Bruno prépare un billet plongeant sous le capot de Koalab !

Petite liste d'événements

2013-01-28T00:00:00+01:00

Nous sommes dans une période où nous regardons les événements à venir pour savoir pour lesquels nous avons particulièrement envie de participer. Il y a beaucoup d'événements intéressants et le choix est donc difficile. Voici ceux que nous avons retenu pour le moment :

FOSDEM, les 2 et 3 février à Bruxelles, est un événement de référence au niveau européen sur l'Open Source.
Je vais faire une introduction à Go le 19 février au GDG Nantes.
Devoxx France, la conférence pour les développeurs passionnés de Java, se tiendra du 27 au 29 mars à Paris.
Nous attendons avec beaucoup d'impatience The Realtime Conference Europe, où nous espérons être à la fois sponsor et speakers. Ce sera les 22 et 23 avril à Lyon
La Conf va proposer un événement Rails de qualité avec des speakers reconnus les 9 et 10 mai à Paris.
Sud Web se tiendra les 17 et 18 mai dans le superbe Palais des Papes, en Avignon, et le programme est très alléchant.
The RubyKaigi 2013 sera l'événement de référence sur Ruby cette année, du 30 mai au 1^er juin à Tokyo et nous y assisterons.
Nous serons également présent à MagmaConf du 5 au 7 juin au Mexique.
Même si rien n'est encore annoncé, nous sommes confiants que cette année encore Ruby Lugdunum sera une conférence de très grande qualité organisée par les rubyistes lyonnais.
L'édition 2013 d'Euruko, la conférence européenne sur Ruby se déroulera les 28 et 29 juin à Athènes.
Sur le thème de la conception web et de ses bonnes pratiques, la Kiwi Party se passera le 28 juin à Strasbourg.
Les Rencontres Mondiales du Logiciel Libre sont un rendez-vous incontournable pour nous. Nous serons présents pour cette édition à Bruxelles début juillet.
Toujours dans le milieu de l'Open Source, nous étudions la possibilité d'aller faire un tour à l'OSCON du 22 au 26 juillet à Portland, Oregon.
Paris Web sera de nouveau présent en 2013, du 10 au 12 octobre pour être précis, et nous comptons bien y participer.

Et maintenant, j'ai une question pour vous : est-ce que vous voyez d'autres événements à ajouter absolument à cette liste ?

URxvt autotransform

2013-01-18T00:00:00+01:00

Beaucoup de langages interprétés nous donnent la ligne où le programme a planté.

Cela donne, par exemple, en Ruby :

app/controllers/admin/users_controller.rb:13:in `edit'

Il arrive souvent de vouloir aller directement à ligne en question. Grace à l'option autotransform d'URxvt c'est possible juste en sélectionnant le fichier:ligne:in qui sera automatiquement copié dans le « clipboard ».

Pour cela, il suffit de mettre dans votre fichier ~/.Xdefaults ou ~/.Xresources :

URxvt.selection-autotransform.0: if(/\\n\\[?\\d\\d(\\d\\d-|:)\\d\\d/) { s{^\\[?[\\d:_-]+\\]? +}{};
    s/\\s*\\n\\[?[\\d:_-]{5,}\\]? +/ || /g; s/^\\s+/ /mg; s/( ?) \*\\n( ?)/($1||$2)/eg; s{ $}{}; };
URxvt.selection-autotransform.1: if(/^irb.*?> /) { s{^irb.*?[>*]\\s*}{}mg; s/\\n=>/ #=>/mg; s{\\n$}{};}
URxvt.selection-autotransform.2: if(m{^[ab]/}) { s{^[ab]/}{}g; }
URxvt.selection-autotransform.3: s/^([^:\\s]*):(\\d+)(:|:in)?$/+$2 $1/g;

Cela transforme le fichier:ligne:in en fichier +ligne. Il ne reste plus qu'à faire un :

$EDITOR <Shift>+<Insert>

Ces expressions régulières ont été écrites par tpope, vous pouvez consulter son .Xresources.

Managing Rails assets with Bower

2013-01-02T00:00:00+01:00

Web applications have been shifting from server to client, and with them a lot more Javascript code and stylesheets are written and, hopefully, re-used. While this is quite an obvious statement, it means that we need an efficient way to manage those assets.

I'd like to write then that this is a simple matter, and that there is one way to do it. But let's face it, every Javascript coder out there has their own ideal solution. So yes we have plenty, which is probably a good thing in a not-immediately-obvious way.

This article is to be pragmatic and short however. As a consequence, I will write about accommodating Rails and Bower, without mentioning AMD, or projects like component that try to solution the “assets problem” in Rails lingo. I hope, we can write about these later on though.

How do you manage vendor assets in Rails?

Well as rubyists go, gem search is a common approach to solving problems. And surely enough there are rubygems that bundle Rails-engines with a bunch of static assets.

For example, you can add the following line to your Gemfile to have the BackboneJS library served through a Rails engine:

gem 'backbone-rails', '~> 0.9.2'

When the asset pipeline requires the Backbone library, it is served by backbone-rails. It looks a little like a case of hammer-nail syndrome: using Ruby packages for Javascript? However some gems also provide Rails generators to save developers the hurdle of bootstrapping their SPA (and a handful of mkdirs). I have mixed feelings about this whole deal: it feels like a hack, but it is a very practical one.

There is another way of managing assets around there. I call it the ostrich approach and it's quite possibly the dirtiest. It merely consists of using wget, or curl, to throw those annoying Javascript files into your vendor directory, and forget about them. Great idea! (j/k it's stupid, don't do that.)

All in all, rubyists do not have much tools to manage static assets.

At af83 we've been playing with Twitter's Bower to manage our Rails app assets for a little while. If you never heard of Bower, imagine Bundler for Javascript code, stylesheets, images: components. And just maybe, have a crash course on how it's used.

Wait… What about Sprockets?

Sprockets is the core of the Rails asset pipeline. It is a very nice tool to help compile/compress your assets in a bandwidth-friendly way. For all the trouble it saves you from, you should love Sprockets. Say it loud now: “I love Sprockets”.

Then again, to be honest, it would be nice if Sprockets also did Bower's job: for example, it could just work should I throw a component.json at it — or, since we're in Ruby land have it load some YAML with a list of components. Maybe that's akin to feature creep though, and a separate gem would keep things simpler.

But that's for another post I hope. Meanwhile, let's see how we can use Bower with Rails.

Setup Bower with Rails

Bower is a step in the right direction: it lets you declare a browser application's dependencies, and their versions, explicitly. It is a (young) nodejs program though, so it doesn't integrate seamlessly with your vanilla Ruby/Rails stack.

The hacker way

Let's start by doing things the hacker-way, and have Bower speak Railsish.

Setup Bower

Using bower to fetch static assets for rails is simple. The first step is to setup a .bowerrc in your Rails root that looks like this:

{
  "directory": "vendor/assets/components",
  "json": "component.json"
}

The directory key sets the destination path,
the json key sets the name of the configuration file.

If the .bowerrc file is missing, Bower will merely reset to its defaults, and install components in the ./components directory.

Second step: specifying Bower dependencies. Use your favorite editor and open the component.json file. Here's a sample that will load the jQuery, Backbone and Lodash libraries:

{
  "dependencies": {
    "jquery": "~1.8.3",
    "backbone": "0.9.9",
    "lodash": "https://raw.github.com/bestiejs/lodash/v1.0.0-rc.3/lodash.underscore.js"
  }
}

Dependencies can be set by version, git repository, local directory, or even links to remote files: check Bower's documentation for a complete list of what you can do here.

Finally, run bower install to fetch and install the dependences:

$ bower install
bower downloading https://raw.github.com/bestiejs/lodash/v1.0.0-rc.3/lodash.underscore.js
bower cloning git://github.com/documentcloud/backbone.git
bower cached git://github.com/documentcloud/backbone.git
bower fetching backbone
bower cloning git://github.com/components/jquery.git
bower cached git://github.com/components/jquery.git
bower fetching jquery
bower checking out jquery#1.8.3
bower copying /home/oz/.bower/cache/jquery/cf68c4c4e7507c8d20fee7b5f26709d9
bower checking out backbone#0.9.9
bower copying /home/oz/.bower/cache/backbone/f184345e8f03dbe160c843ce1b7248eb
bower installing jquery#1.8.3
bower installing backbone#0.9.9
bower installing lodash

If you check the vendor/assets/components directory, each dependency is now sitting under its own subdirectory.

Setup Rails

Now that we fetched some static files, they must be loaded through Rails' asset-pipeline. Since we installed those files under vendor/assets/components, we need to add a line to config/application.rb to add the directory to our assets path:

config.assets.paths << Rails.root.join('vendor', 'assets', 'components')

(Don't forget to restart your Rails server after this one.)

Your assets are now ready for consumption. Sprockets will happily load them…

But there's a catch: unless you're running the latest release of Sprockets (starting at ~> 2.6) you can not require jQuery by applying the usual //= require jquery. Instead, you have to //= require jquery/jquery.

Why is that? Well, Bower stores the libraries where you tell him, under neatly ordered directories. Bower also expects the library to come with his own component.json to describe itself: name, authors, version, etc. More importantly in our case, this file should point to an entry point. In jQuery's case, you will have to require the library with //= require jquery/jquery. Meh.

In fact, you may be left on your own to have a look a each component's directory in order to require the appropriate file; that is, unless you're running a "recent" release of Sprockets that will do just that for you (hang in there, Rails 4 is coming). Did I mention how much I love Sprockets?

Setup your VCS

Ignoring the vendor/assets/components directory is a good idea since you don't want to commit more than your components.json file. If you're using Git, the following should do the trick:

$ mkdir vendor/assets/components
$ touch vendor/assets/components/.gitkeep
$ git add vendor/assets/components/.gitkeep
$ echo /vendor/assets/components >> .gitignore
$ git add .gitignore
$ git commit -m 'Setup bower components directory'

And that's all there is to it.

Using the bower-rails gem

Why, of course there is a gem that does all the tedious work for you. And it's quite simple too.

Ross Harrison's bower-rails adds two rake tasks to read a list of components from a bower.json file. Those are then installed under vendor/assets/javascripts/, or lib/assets/javascripts directories. The naming is a bit off when/if you're installing things like Twitter Bootstrap, that contain stylesheets, but in the sake of simplicity let's ignore this for now.

Here is a sample bower.json file straight from the project's README:

{
    "lib": {
        "dependencies": {
            "threex"      : "git@github.com:rharriso/threex.git",
            "gsvpano.js"  : "https://github.com/rharriso/GSVPano.js/blob/master/src/GSVPano.js"
        }
    },
    "vendor": {
        "dependencies": {
            "three.js"  : "https://raw.github.com/mrdoob/three.js/master/build/three.js"
        }
    }
}

What the gem really does is chdir here and there, rewrite this JSON to a valid Bower format, and exec bower install. It's easy as pie, and painless for Ruby developers.

Wrapping up

Although I really like Javascript (and its bizarre quirks), I don't like to add heterogeneous tools to a developer's environment when it can be avoided: increased complexity, and maintenance, are not helping your productivity. I won't argue in favor or against nodejs here. However I doubt you prefer downloading files into vendor/, over having a program do the job better that you would. Bower is simply too good to ignore. :)

Les défis du développement des single page webapps

2012-12-18T00:00:00+01:00

Les single page webapps, vous savez ces petites applications écrites totalement en HTML5, JavaScript et CSS3, sont à la mode. Elles permettent d'offrir une expérience utilisateur optimale, sans la lenteur des changements de page. Mais pour ça, encore faut-il qu'elles soient développées dans les règles de l'art.

Cet article vise à montrer quels sont les défis que l'on rencontre lors du développement de telles applications et présente comment, chez af83, nous y répondons.

La façon naïve de développer une single-page webapp

Un développeur expérimenté dans les sites web mais qui se lance pour la première fois dans une single page webapp sera tenté de faire comme à son habitude :

utiliser jQuery
sélectionner des plugins jQuery pour chaque fonctionnalité
vérifier rapidement que ces plugins sont d'une qualité suffisante
écrire un peu de code pour faire la glue entre tout ça.

Et, au début, ça ne va pas trop mal marcher. Oh, bien sûr, il y aura quelques bugs par-ci par-là, mais rien de bien méchant. Comme pour les sites web, certains plugins vont se marcher sur les pieds et il faudra corriger ça. Mais, pour notre développeur, cela reste du domaine connu.

Pourtant, au fur et à mesure qu'il va continuer à avancer, cette situation va vite se dégrader. Notre développeur va rencontrer de plus en plus de bugs. Et il passera plus de temps sur la correction de bugs, il avancera moins vite sur les fonctionnalités.

Puis, il va arriver à un point où il va devoir commencer à réécrire certains plugins jQuery pour réussir à corriger les bugs qu'il rencontre et continuer à avancer. Comme si ce n'était pas assez compliqué, notre développeur se rend également compte que les performances de son application se dégradent rapidement : ça devient moins fluide, le temps de chargement initial s'allonge. Mais comme il n'a pas le temps d'optimiser ça, il cache la misère en rajoutant des loaders.

Et le pire finit par arriver. Notre développeur n'arrive plus à s'en sortir dans son code : il ne comprend plus comment ça marche. Chaque modification ou nouvelle fonctionnalité entraîne des tas de nouveaux bugs. Même la correction d'un bug fait apparaître de nouveaux bugs.

Malgré tous ces efforts, l'application est lente et buggée et les utilisateurs ne sont donc pas au rendez-vous. Si vous en arrivez à ce point, il ne vous reste plus qu'une solution : vous accrocher à l'espoir d'une V2.

Mais quelles sont les clés pour comprendre cet échec ? Nous pouvons isoler 3 grandes limitations de cette approche :

Le développement d'une telle application doit être maîtrisé et structuré, or les plugins jQuery rendent très difficiles la mise en place d'une telle structure.
Il est crucial de prendre en compte les performances, et tout particulièrement dans le contexte de pages qui restent longtemps ouvertes.
L'absence d'outils fait perdre beaucoup de temps au final.

Voyons plus en détails ces 3 défis.

Structure et maîtrise

Comme pour toute application, le développement sur le long-terme se passe d'autant mieux quand il est maîtrisé, c'est-à-dire quand les développeurs arrivent facilement à comprendre quels seront les effets des modifications qu'ils apportent mais également quand il est facile pour un développeur externe de rentrer sur le projet.

L'agglomération de plugins jQuery est problématique de ce point de vue, car, ils se comportent comme des boîtes noires mais surtout leurs interfaces sont très limitées. Le code qui fait la glue entre ces éléments se retrouve alors très fragile car il oblige à avoir un couplage fort entre les plugins.

Pourtant, il n'est pas si difficile de structurer le code d'une application JavaScript. Les principes sont d'ailleurs très similaires à ceux des applications web classique ou desktop :

Utilisation d'un framework MVC (chez af83, nous avons une préférence pour Backbone mais AngularJS ou Ember sont de très bonnes factures également)
Respect de conventions de codage (jshint)
Séparation du code en plusieurs fichiers avec une classe par fichier (nous utilisons les classes fournies par CoffeeScript)
Emploi de templates pour le code HTML généré (avec handlebars ou jade par exemple)
Utilisation d'événements/signaux au couplage fort entre composants (avec Backbone, cela vient naturellement via le module Events).

Performances et optimisations

Le deuxième défi des single page webapps est le coté performances. Cela couvre beaucoup d'aspects : temps de chargement, fluidité des animations, réactivité, endurance, etc.

J'aurais beaucoup à dire sur chacun de ces points mais globalement l'approche est toujours la même. On commence par se fixer des objectifs, idéalement de manière formelle mais, dans la pratique, c'est souvent un ressenti assez subjectif qui sera le déclencheur. Si un de ces objectifs n'est pas atteint, on va s'appliquer à améliorer ça. Mais avant tout changement, il convient de mesurer pour détecter où le bât blesse. Les optimisations en aveugle sont souvent inefficaces et on fait perdre beaucoup de temps. Donc, surtout, avant de commencer à optimiser un point, il faut être confiant que ce point entre bien en compte dans notre objectif. Enfin, il ne reste plus qu'à optimiser et vérifier que l'on s'est bien rapproché de notre objectif.

Je pourrais entrer plus dans les détails mais cette méthode est très classique et je ne pense pas que cela apporterait grand chose.

Par contre, je souhaite parler d'un point un peu particulier qui est souvent négligé : ces webapps sont souvent utilisées pendant une longue période de temps sans rechargement et cela a un fort impact sur les performances.

En effet, le nombre d'objets JavaScript, de nœuds dans le DOM, de listeners d'événements, etc. a tendance à grossir et à consommer beaucoup de mémoire, au point de rendre la webapp très lente.

Par exemple, Google a montré que Gmail pouvait facilement prendre plusieurs Go de mémoire vive et a expliqué les optimisations qu'ils ont mises en place pour réduire ce gouffre en termes de performances.

Pour les objets JavaScript, les Garbage collectors des navigateurs ont fait de grand progrès ces derniers temps. En respectant quelques principes, comme éviter de créer des objets inutiles dans des boucles, il y a peu de surprises.

Plus difficile, la gestion des nœuds du DOM et des listeners associés a un impact plus conséquent et est plus difficile à maîtriser. Il convient de faire particulièrement attention à ne pas leaker des fragments de DOM. Pour des pages web que l'on recharge régulièrement, le problème passe inaperçu mais sur une webapp qui reste ouverte pendant quelques dizaines minutes, cela peut ralentir très fortement les navigateurs.

Jusqu'à récemment, le « ménage » de ces éléments avec Backbone devait se faire manuellement. Heureusement, un grand travail a été effectué ces derniers mois et la version 0.9.9 permet d'en récolter les fruits. La gestion de la mémoire s'en trouve grandement simplifiée si l'on respecte les best practices de Backbone. Il reste des cas où l'expertise d'un dév front confirmé reste nécessaire, mais ces cas restent très rares.

Sans outils, point de salut

J'ai déjà cité pas mal d'outils ci-dessus : Backbone, CoffeeScript, Handlebars, etc. Mais, je vais insister sur ce point.

Pour construire un site web avec quelques effets JavaScript, on pouvait facilement s'en sortir en faisant tout manuellement ou avec quelques scripts maison. Mais, comme pour les applications web coté serveur, c'est l'utilisation de frameworks, outils et bibliothèques qui a permis de passer à la vitesse supérieure. Grâce à eux, nous avons pu gagner fortement en vélocité et nous attaquer à des projets bien plus complexes.

Le même cheminement est valable pour les applications coté client. Cela peut faire peur aux nouveaux venus dans ce domaine car la barrière à l'entrée est plus importante. Mais c'est un fonctionnement indispensable pour réussir des projets plus conséquents.

Un de ces outils est grunt. C'est une sorte de Makefile pour le front dev. Il vient avec de nombreuses extensions pour compiler des fichiers CoffeeScript ou Sass, concaténer des fichiers, réduire le poids des fichiers générés, lancer des tests, etc. Sans lui, il faudrait faire toutes ces tâches manuellement (ou avec des scripts maison), ce qui serait une grosse perte de temps et peut conduire à introduire des bugs dans ce processus.

Autre exemple, Bower. C'est un outil qui permet d'installer facilement des bibliothèques CSS et JS et d'en gérer les mises à jour. Pour un site web, on peut facilement s'en passer : on va sur le site web de chaque bibliothèque, on regarde ce qu'elle fait et si ça nous convient, on télécharge le code et on le met quelque part.

Pour une application, c'est plus problématique. D'une part, le nombre de bibliothèques utilisées est plus important. D'autre part, ces bibliothèques sont plus complexes et ont souvent des dépendances. On se retrouve alors à devoir jongler entre les versions pour trouver un ensemble cohérent.

Puis, vient le problème des mises à jour. Quand on veut mettre à jour une bibliothèque, il faut retrouver où on l'avait téléchargée, quelles sont ses dépendances, etc. Ce n'est pas forcément très compliqué mais on peut vite y perdre pas mal de temps.

Avec bower, la liste des bibliothèques est déclarée dans un fichier component.json, avec la version utilisée. En une ligne de commande, on peut mettre à jour une bibliothèque ou en installer une nouvelle.

Bien entendu, je pourrais continuer à lister d'autres outils (intégration continue, scripts de déploiement, couverture de code…) mais je pense que vous avez compris l'idée !

En deux mots

Le développement front a souvent été considéré comme étant plus facile que le développement back. Je pense que cette époque est révolue et que les single page webapps sont au moins aussi complexes que les applications plus classiques. Pour les réussir, il convient donc de changer d'état d'esprit et réussir à transposer les clés de la réussite des applications web classiques :

Utiliser un framework pour structurer son code
Écrire des tests
Sélectionner un ensemble efficace d'outils
Se fixer des objectifs de performances, les mesurer et optimiser lorsque c'est nécessaire
S'appuyer sur des développeurs expérimentés pour poser le cœur de l'application.

API Days

2012-12-17T00:00:00+01:00

Il y a quelques jours se sont déroulées les API Days, organisés par Fabernovel et Webshell. Les conférences ont couvert un large spectre des API, d'un point de vue à la fois technique et commercial. Cet évènement a aussi permis de démontrer le potentiel des API en termes d'usages : en ramenant de la transversalité entre les sources de données, les API permettent de créer des services plus proches des parcours d'usages réels des personnes.

Certains exemples au succès avéré revenaient régulièrement : Netflix, Shopify, Amazon, Facebook, etc. Mais les API ouvrent des opportunités dans de nombreux autres secteurs, comme par exemple le journalisme. Plusieurs médias étaient d'ailleurs présents (France Télévision, L'Express, Le Monde, Rue89, Les Échos) pour expliquer leurs positionnements sur le sujet.

Voici 3 aspects des API, abordés à travers 3 conférences, qui m'ont particulièrement intéressée.

Les API dans l'histoire du web

Dans sa conférence "Future Interface: What the last 50+ years of modern computing history may tell us about the future", Mike Amundsen (Layer7) balaie les 50 dernières années de l'histoire du web et ses différents acteurs pour remettre en perspective les enjeux des API.

En 1945, Vannevar Bush tente déjà de relier les informations des humains à distance au moyen de la machine qu'il avait conçue, le Memex.
En 1963, Ted Nelson poursuit la réflexion de V.Bush et décrit plus précisément le fonctionnement de ces liens. Il invente la notion d'hypertexte.
A la même époque, Douglas Engelbart met au point le hardware qui permet de faire réellement fonctionner et d'incarner ce réseau de liens.
Puis en 1965, Christopher Alexander identifie les patterns pour penser et agir dans ce réseau (notions de maillage et de noeuds plutôt que d'arborescence).
Dans les années 90, Tim Berners Lee part des hypertext de T.Nelson et développe le HyperText Transfert Protocol (HTTP)
Roy T. Fielding construit ensuite les nouveaux systèmes basés sur ces patterns (architecture REST).

Plus récemment, M. Amundsen cite :

Github qui donne une nouvelle envergure au Memex de Vannevar Bush en rendant effectivement possible des interactions collaboratives à distance (de temps et d'espace).
Ryan Dahl a également contribué à traiter la latence en créant NodeJS.
Enfin Eric Schweikardt a poursuivi la réflexion en concevant des systèmes qui accompagnent et stimulent les comportements émergents, à travers son projet Cubelets.

En s'appuyant sur ce bref historique, M. Amundsen démontre que le web tend vers les mêmes objectifs depuis le début : des briques faciles à combiner, un système capable d'opérer de façon largement distributive. Tout cela dans le but d'augmenter les capacités intellectuelles de l'homme. Les API se positionnent dans la suite logique de cette évolution.

API et internet des objets : vers une API unique ?

Dans "API and ubiquity", François Daoust (Joshfire) explore les enjeux des API liés à l'Internet des objets.

Le fait que les objets deviennent "connectés" requière que l'utilisateur puisse accéder au contenu sur n'importe quel device, quel qu'il soit. Cela implique notamment de pouvoir dissocier le contenu du contenant (le js des données par exemple), d'être "provider agnostic" autant que possible, et de privilégier l'exécution côté client.

Il y a néanmoins deux problèmes majeurs :

chaque fournisseur de contenu définit sa propre API, souvent propriétaire
chaque fournisseur de contenu définit aussi sa propre structure de réponse (xml ou json par exemple, avec un vocabulaire propre)

L'enjeu est donc d'aller vers une seule API REST read/write pour tout, avec un vocabulaire et une syntaxe commune pour décrire les objets web.

F. Daoust propose pour cela d'utiliser json-ld ("ld" signifie linking data). Ce format vise à utiliser un seul nom pour chaque chose, en définissant des types comme schema, person, name, etc. Cela permet ensuite d'effectuer une conversion automatique entre les contextes, sans bouleverser les méthodes de développement.

Actuellement, la syntaxe de json-ld est stable, l'API est en cours de finalisation. Elle est notamment utilisée sur Joshfire Factory, l'outil de développement d'application créé par Joshfire.

API et open source

Dans sa conférence "Why open", S. Klabnik s'appuie sur les concepts de Gilles Deleuze pour penser les enjeux open source liés aux API.

Il propose ainsi qu'Internet, de même que les entreprises, ne sont pas des entités définies et fermées, mais au contraire des agencements d'éléments divers. Ces agencements sont en constant rééquilibrage : telle entreprise en rachète une autre, intègre ses composants et redéfinit ainsi son propre périmètre d'actions et d'acteurs. C'est ce que Deleuze nomme la dé-territorialisation et la re-territorialisation.

Les API exacerbent ces processus d'agencement et de "déterritorialisation" : des sociétés de tout secteur vont utiliser l'API de Facebook, ainsi vont-elle bouleverser leur périmètre actuel (dé-territorialisation) pour intégrer les possibilité de cette API et définir un nouveau périmètre de fonctions, d'usages (re-territorialisation).

Cela crée un important enjeu industriel et économique : la plupart des entreprises souhaitent mettre en place des API qui valorisent leurs données et diffusent leurs services, mais craignent de perdre leur travail en ouvrant trop ces API. C'est le cas par exemple de Twitter qui entend partager son API tout en contrôlant son utilisation/accès.

Le problème, explique S. Klabnik, c'est qu'on ne peut pas partager quelque chose et en même temps vouloir le contrôler. En ouvrant son API et en permettant aux gens de participer au développement de nouvelles fonctionnalités/contenus, l'entreprise évolue mieux et plus rapidement, et les utilisateurs sont d'avantage impliqués dans le service.

Pour conclure

Ces conférences ne représentent donc que 3 aspects des API. De nombreux autres aspects ont été abordés, tels que le temps réel (au sujet desquels Bruno Michel, notre CTO, a d'ailleurs fait une présentation intitulée "Welcome to the evented age"), l'hypermédia, la valeur commerciale des API, "l'évangélisation" que cela implique dans les entreprises, etc. Le sujet est donc vaste… Vivement la prochaine édition !

Pour en savoir plus :

Ruby 2.0 : Enumerator::Lazy

2012-11-22T00:00:00+01:00

With the release of a first preview during RubyConf 2012, the release of Ruby 2.0 is getting closer.

After Module#prepend, Module#refine, let's talk about Enumerator::Lazy.

Chainable iteration

Given this nonsensical example:

hashes = (1..10000).select(&:even?).map(&:hash).map(&:to_s)

This code does the following:

keeps only even numbers
fetches their internal hash
transforms those hash in String

But it also creates a intermediate array for each block, and iterates several times.

That can be done in one iteration:

hashes = (1..10000).inject([]) do |accumulator, number|
  if number.even?
    accumulator << number.hash.to_s
  else
    accumulator
  end
end

Let's face the truth: the code is less readable.

Enumerator::Lazy

Here comes the laziness.

hashes = (1..10000).lazy.select(&:even?).map(&:hash).map(&:to_s).to_a

When to_a is called, the code is evaluated. Internally, Ruby builds a specific block: no intermediate arrays are created and only one iteration occurs.

Without calling to_a (which is an alias to the force method), it returns a Enumerator#Lazy object.

#<Enumerator::Lazy: #<Enumerator::Lazy: #<Enumerator::Lazy: #<Enumerator::Lazy:
1..10000>:select>:map>:map>

Benchmarking

Since there is only one iteration, it should be faster. Well, let's run some benchmarks first.

require 'benchmark'

[10000, 100000, 1000000, 10000000].each do |size|
  Benchmark.bm do |b|
    b.report("chainable #{size}") do
      hashes = (1..size).select(&:even?).map(&:hash).map(&:to_s)
    end
  end

  Benchmark.bm do |b|
    b.report("one iteration #{size}") do
      hashes = (1..size).inject([]) do |accumulator, number|
        if number.even?
          accumulator << number.hash.to_s
        else
          accumulator
        end
      end
    end
  end

  Benchmark.bm do |b|
    b.report("chainable lazy #{size}") do
      hashes = (1..size).lazy.select(&:even?).map(&:hash).map(&:to_s).to_a
    end
  end
end

So, Enumerator#Lazy seems to be the slowest in every case. According to a bug report, the cost of block creation for laziness is bigger than its gain. That being said, those benchmarks need to be rerun when Ruby 2.0 will be released.

As pointed out in this bug report, there are some cases where Enumerator#Lazy is definitely the best choice you can make. For example, you can use it when extracting elements from a huge, or even infinite enumerator.

Prime.select {|x| x % 4 == 3 }.take(10)

This code iterates on all prime numbers before doing a select, then a take. However, it will iterates indefinitely and will never do the select nor the take.

a = []
Prime.each do |x|
  next if x % 4 != 3
  a << x
  break if a.size == 10
end

This code would do the job, but is not easily readable.

With lazy, we can do:

Prime.lazy.select {|x| x % 4 == 3 }.take(10).to_a

This would return immediately, and provide a good readability.

Coming next in this series: Named arguments.

Release: gaston, a configuration store for Ruby

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

Gaston is a store configuration that can be used in any Ruby project, it was released a bit more than year ago. We use it on most of our Ruby projects but Gaston didn't have the honours of a blog post yet.

Installation

Ruby 1.9.2 is required.

Install it with rubygems:

gem install gaston

With bundler, add it to your Gemfile:

gem "gaston"

Environment

Let's take a look at this yaml file containing some configuration values.

:gaston:
  :api:
    :state: "awesome"
:development:
  :api:
    :token: "api_token"
:test:
  :api:
    :token: <%= ENV["API_TOKEN"] %>

Gaston allows to specify different values depending on the environment. The gaston environment represents the default values that all environments inherit, unless a given value is overwritten in a specific environment.

In development environment, calling Gaston.api will yield the following hash:

{
  "state" => "awesome",
  "token" => "api_token"
}

In test environment (with the Environment variable set to "269596961710045034"), calling Gaston.api will yield the following hash:

{
  "state"=>"awesome",
  "token" => "269596961710045034"
}

This example also shows that gaston accepts Ruby code as a value through ERB templating.

Gaston also accepts json files:

The same rules apply here.

A small setup is required to use Gaston. You can define an environment with the env method and specify config files with the files method. Default env is :development.

require 'gaston'

Gaston.configure do |gaston|
  gaston.env = ENV['ENV']
  gaston.files = Dir['*.yml', '*.json']
end

Gaston.api
# => {:state=>"awesome", :token=>"api_token"}
Gaston.hostname
# "dev.af83.com"

One last thing

At its core, Gaston inherits from the Ruby core class Hash. A Gaston store give access to all the methods defined on the Hash class. So you can use the classic keys, fetch methods. In order to do that, Gaston does not allow key names that are also a method defined on Hash. In this case, Gaston does not add this part of the configuration and logs a warning.

Ruby 2.0 : Module#refine

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

We already talked about Module#prepend as one of the new features of the upcoming Ruby 2.0… Today, let's talk about refinements. Refinements had landed into trunk, but is actually reviewed. It could eventually be reverted for performance issues.

Why refinements

Because Monkey patching: Monkey patching is a powerful feature, but as everybody knows, with great power comes great responsibility. Refinements intend to give you the power of Monkey patching, but without messing with the whole universe of the Ruby runtime.

Module#refine

module FooBar
  refine String do
    def hello
      puts "#{self} says : Hello, world"
    end
  end
end

class Bar
  using FooBar
  attr_reader :user

  def initialize(user)
    @user = user
  end

  def say
    user.hello
  end
end

Bar.new('af83').say
String.new.say

In the module FooBar, we use the class method refine to enhance the class String. And in the class Bar, we declare that we want to use FooBar with the using methods.

Running this code with Ruby 2.0 outputs the following:

af83 says : Hello, world
refinements.rb:23:in `<main>': undefined method `say' for "":String (NoMethodError)`'`

What's happening here

When we call Bar.new('af83').say, the addition of the method hello on the class String is only effective in the context of the Bar class, thanks to the use of using FooBar.

On the contrary, String.new has no knowledge of the method say. Hence, the NoMethodError.

Like I said, safer monkey patching. :)

Resource

You can read the whole story of refinements in Ruby.

Coming next in this series: Enumerator::Lazy.