Rappel

Redis est une base de données “clés/valeurs”. C’est une manière de stocker et accéder aux données très différente des système relationnels tels que MySQL, Oracle, …

Pour comprendre le fonctionnement de Redis, je conseille la lecture du livre de Karl Seguin : The Little Redis Book.

Le serveur Redis (redis-server) est une application autonome, qui fonctionne avec un seul thread, accessible via un port TCP ou bien un socket système.

Il dispose de plusieurs bases internes, dont la seule distinction est un numéro d’ordre. Il y en a 16 par défaut (c’est configurable) et si le client ne spécifie pas de base particulière, il est connecté à la première (numérotée 0).

Au sein d’une base, Redis stocke des objets typés (les valeurs), accessibles par un index unique (les clés). Une clé est une simple suite de caractère, par exemple “metrics:users:count”. Le choix du “:” comme séparateur “sémantique” est totalement arbitraire et laissé au choix du développeur et permet de facilement reconstituer mentalement une arborescence de clés. Aux yeux de Redis, l’exemple précédent est strictement identique à “metrics/users/count”, “MetricsUsersCount” ou même “hello”.

Séparer ses données

Lorsqu’on manipule des données dans des contextes différents le risque est de contaminer les données d’un contexte depuis un autre contexte. Il convient alors d’utiliser un système qui permet de ne pas mélanger les données selon le contexte. Pour un projet qui peut fonctionner dans des environnements de test, développement et de production, les données doivent être partitionnées.
Si on a plusieurs projets en simultané, il faut également séparer leurs données.

La première approche est d’utiliser un espace de nommage. Encore une fois, pour Redis ça n’est pas une fonction particulière, mais juste une convention de nommage des clés. On peut alors préfixer nos clés par le nom du projet et son environnement : “projet1:dev:metrics:users:count” sera alors bien séparé de “projet2:prod:metrics:users:count”.

Le problème avec cette approche est que pour Redis, tout est dans le même panier. Il devient impossible de supprimer toutes les clés du “projet 1” uniquement. De même parcourir le contenu de la base à la recherche d’une clé est moins facile.

On peut alors utiliser une base interne différente pour chaque projet. Il conviendra alors au client de se connecter à la bonne base, mais ensuite tout est bien séparé.

Le problème est que Redis ne permet pas de nommer les bases internes, elles sont simplement numérotées. Il n’y a pas non plus de configuration particulière pour les bases (persistance, sécurité, …). Rien n’empêche un client de se connecter à la mauvaise base d’y mettre la pagaille.

De plus, le support des bases internes multiples va être déprécié ne sera pas supporté dans Redis Cluster, il est donc prudent d’étudier une autre alternative.

Il reste une troisième solution ; 1 serveur Redis par projet.

Configurer et utiliser plusieurs instances

Le serveur Redis est un simple binaire qui n’a aucun mal a être lancé plusieurs fois en parallèle. Par défaut il va chercher sa configuration à un emplacement prédéfini, mais rien n’empêche de le lancer avec une configuration spécifique à chaque fois.

Les variations minimales à faire entre les configurations sont au moins le moyen d’accéder à l’instance (port TCP ou socket système) et l’emplacement des données.

Il suffit de créer un fichier de configuration et un script d’initialisation pour chaque instance et le tour est joué.

Le choix d’en faire une pour chaque environnement au sein d’un même projet n’est pas si compliqué :

• sur un serveur il n’y a le plus souvent que l’instance de “production” ;
• sur le poste d’un développeur, il peut y avoir une instance de “développement” (permanente ou lancée au besoin) ;
• pour un environnement de “test”, on peut avoir une instance démarrée à la volée, sans persistance sur le disque. Elle est donc re-initialisée à chaque fois, ce qui convient assez bien à ce type d’usage ;

Avantages des instances multiples

Il existe plusieurs grands avantages à utiliser Redis de cette manière

Une séparation stricte des données ; une fois connecté à un serveur, seules les données qu’il gère sont accessibles, sans risque de pollution. La sauvegarde/copie/déplacement des fichiers de persistance devient triviale, le vidage éventuel d’une base devient sans risque pour les autres données.

Une configuration adaptée ; il est possible de gérer la persistance des données de manière différente pour chaque instance, mais aussi d’utiliser un socket système pour certaines et un port TCP pour d’autre, des protections par authentification (ou pas), ou tout autre paramètre de configuration.

Une utilisation à la demande ; il est possible de ne lancer telle ou telle instance du serveur que lorsque c’est nécessaire. Sur un serveur en production, elles seront probablement toutes lancées en même temps, mais en développement ou sur un serveur d’intégration continue ça peut être utile (avec Foreman par exemple).

Une supervision spécifique ; on peut mettre en place des outils de supervision adaptés à chaque instance en fonction de son niveau de criticité. Une instance critique pourra être suivie de très près (y compris avec des tests sur la présence de clés/valeurs spécifiques), avec des graphiques exhaustifs sur les ressources, … Dans le même temps, une autre instance pourra être simplement testée sur le fait que son processus est bien présent et rien d’autre.

Il est important de noter que chaque instance du serveur Redis n’occupe qu’environ 1 Mo de ram (hors données stockées). le surcoût est donc minime, voire négligeable.

Conclusion

À partir du moment où plus d’un projet doit accéder à une base de données Redis, je ne vois que des avantages à disposer d’une instance de redis-server pour chaque projet.

J’ai pu en bénéficier quelques fois à mes débuts (trop peu à mon goût, d’ailleurs) et ça m’a beaucoup servi.

C’est pourquoi je voudrais consacrer un peu de mon temps, régulièrement (et gratuitement), pour accompagner des personnes qui souhaiterais avoir un œil extérieur sur leur code, leurs pratiques, leurs méthodes, leurs outils, …

Il ne s’agit pas de formation au sens institutionnel du terme, mais plutôt d’observation, de critique et de conseil, dégagé de tout troll (dans la mesure du plus possible).

Je propose donc de passer 30 minutes à 1h en tête-à-tête, lors de chaque réunion du PLUG, avec une personne pour une séance de pair-programming, ou de discussion technique sur un sujet, … Ça peut être sur mes technos de prédilection, mais aussi sur n’importe quel langage, framework, … ou sur des méthodes de travail car il ne s’agit pas forcément de décortiquer le détail de chaque ligne, mais pourquoi pas d’avoir un regard critique d’ensemble, …

Faites moi signe (en commentaire, par e-mail, via Twitter, …) si vous êtes intéressé. On peut faire une tentative dès la prochaine réunion du PLUG, le 4 novembre. En cas de demandes multiples, je me réserve la liberté de choisir le sujet avec lequel je me sentirai le plus à l’aise ou le plus intéressé.

Mise à jour (21/11/2011) : La première tentative est concluante (pour moi au moins), donc je propose de recommencer dès la réunion du PLUG le 2 décembre.

Voilà une idée bien saugrenue, je vous l’accorde. Pour comprendre, voyons un peu le contexte.

Nous avons développé une application iPhone pour HotelHotel (le site sur lequel je travaille). Elle fonctionne en interrogeant notre API interne pour effectuer des recherches d’hôtels. L’API interroge nos partenaires compare les prix et compose une liste de résultats renvoyée à l’application iPhone.

Pour les hôtels, nous disposons de plusieurs photos, qui aident à se faire un avis sur les hôtels proposés. Ces photos sont gérées par nous mêmes, nous indiquons juste leur URL à l’application distante.

Jusqu’à ces derniers jours, nous stockions ces photos sur notre propre serveur, mais pour différentes raisons, nous les avons déportées vers le service Amazon S3. Il y a plein d’avantages à utiliser ce service : haute disponibilité des contenus, bande passante très importante, pas de soucis de croissance de l’espace utilisé, … pour un coût très raisonnable.

Nous avons donc modifié les différentes parties de notre système pour que les fichiers soient placés sur Amazon S3 et les URL renvoyées aux navigateurs, application iPhone, … soient celle sur Amazon S3 et plus sur notre serveur.

Le problème

Jusqu’ici tout va bien, ou presque. Nos différents sites web (public, admin, …) fonctionnent bien, en lecture comme en écriture. Pa contre, l’appli iPhone plante et quitte dès qu’on veux charger une photo.

Après une séance de debuggage un peu déconcertante, on fini par trouver la source du problème. Pour bien comprendre, je rembobine un peu.

Pendant la phase de développement de l’appli iPhone, nous utilisions une version privée de l’API, sur un sous-domaine spécial, protégé par une authentification HTTP Basic. Juste avant la publication sur l’AppStore, nous avons changé le réglage pour pointer sur l’API de "production", mais nous avons oublié d’enlever les en-têtes d’authentification.
On ne s’en est pas rendu compte car le serveur de production les ignorait. Il n’en attendait pas donc peu importe, il laissait tout passer.

Maintenant que les URL des images sont chez Amazon S3, et plus chez nous, ce sont leurs serveurs qui reçoivent les informations d’authentification. Manque de bol, leur serveur HTTP n’aime pas du tout les authentification de type HTTP Basic et il renvoi systématiquement une erreur 400 (Bad Request). Le contenu de la réponse est quant à lui une portion XML indiquant plus d’infos sur la requête, et c’est probablement ça qui fait planter l’appli. La librairie utilisée n’arrive probablement pas à gérer un contenu XML au lieu d’un contenu image.

Corriger l’appli iPhone pour supprimer l’authentification est très simple, mais il faut ensuite soumettre une nouvelle version à Apple (plusieurs jours de délai pour la valider) puis attendre que l’extrême majorité de nos utilisateurs mettent à jour l’appli, … Ce délai n’était pas envisageable.

La solution

Il m’est donc venue l’idée bizarre de mettre en place un moyen d’intercepter les URL demandées par l’iPhone, de les nettoyer des en-têtes d’authentification et de les transmettre à Amazon S3.

La mise en œuvre a été simple et rapide (grâce à l’aide de Grégory Colpart de Evolix). Nous avons créé un VirtualHost Apache sur un sous-domaine, dans lequel nous avons paramétré un reverse proxy. Toutes les requêtes envoyées à ce sous-domaines sont transmises de manière transparent à Amazon S3, et la directive RequestHeader supprime les en-têtes d’authentification.

Voilà la config du VirtualHost :

    <VirtualHost *:80>
      ServerAdmin webmaster@example.com
      ServerName s3tmp.example.com

      ProxyRequests Off
      <Proxy *>
        Order deny,allow
        Allow from all
      </Proxy>  

      ProxyPass / http://s3.example.com/
      ProxyPassReverse / http://s3.example.com/

      RequestHeader unset authorization
    </VirtualHost>

NB : "s3tmp.example.com" est le sous-domaine du proxy, "s3.example.com" est un alias vers Amazon S3

Contexte

Je souhaite quantifier le volume d’images transférées depuis un de mes serveurs. Le meilleur endroit pour trouver cette info me semble être les fichiers de logs d’Apache (ou autre serveur web) puisqu’ils indiquent l’URL demandée, le code HTTP et la taille du fichier transmis.

Une fois isolés les logs que je souhaite analyser, il ne me restait plus qu’à extraire les bons chiffres et en faire une somme.

Solution

grep '/system' * | grep -o -E '\b200 [0-9]+\b' | cut -f 2 -d ' ' | awk '{sum+=$0} END{print sum/1024/1024}'
Je vous décortique chaque étape du processus, séparées par le "pipe" (tuyau) qui sert à transmettre le résultat d’une commande à la suivante.

grep ‘/system’ *

grep permet de lire le contenu d’un fichier ou d’un flux et d’en extraire des parties, selon des règles et filtres. Je lui demande donc de lire tous les fichiers logs (le * à la fin), à la recherche de "/system" (la base des URLs qui m’intéressent).

J’obtiens donc toutes les lignes de log où une URL qui contient "/system" a été demandée.

Exemple :

178.48.252.123 - - [12/Dec/2010:07:12:11 +0100] "GET /system/images/missing-sq128.jpg HTTP/1.1" 200 2237 "http://www.hotelhotel.com/stylesheets/hh.css?1291888120" "Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12"

grep -o -E ‘\b200 [0-9]+\b’

Les lignes sont analysées une nouvelle fois avec grep à la recherche d’une expression régulière qui permettra d’isoler les requêtes soldées par un code HTTP 200, indiquant que l’image a été effectivement téléchargée.

On utilise l’option -E pour indiquer qu’on veut les expressions régulières "étendues". L’option -o indique qu’on ne veut renvoyer que ce qui a été capturé par l’expression, et pas tout la ligne.

L’expression indique qu’on souhaite capturer ce qui commence par "200", précédé d’une rupture de mot (donc un espace, une ponctuation, …), puis un espace, une suite de chiffres, et une rupture de mot.

Exemple :
200 2237

cut -f 2 -d ‘ ‘

cut permet de découper la chaîne de caractère et de renvoyer seulement certaines portions de cette chaîne.

L’option -d on indique qu’on veut découper selon les espaces. L’option -f indique qu’on veut renvoyer le 2ème segment (la taille de l’image)

Exemple :
2237

À ce stade, on obtient une série de ligne qui contiennent les tailles des images téléchargées, il reste à en faire la somme

awk ‘{sum+=$0} END{print sum/1024/1024}’

awk est un outil aussi génial que les autres utilisés ici, mais je le connais très mal. C’est Colin qui m’a proposé cette dernière commande.

On demande donc à awk de faire la somme des valeurs trouvées à chaque ligne, de renvoyer cette somme, préalablement convertie en mega-octets (dans les logs Apache, ce sont des octets)

Conclusion

J’ai donc pu faire des opérations pas trop complexes, mais pas non plus triviales, en une seule ligne et avec un résultat immédiat.

Encore fois, ça prouve que bien connaître ses outils permet de travailler efficacement.

Inutile de dire que j’ai passé plus de temps à écrire ce petit article que pour construire cet enchaînement de commande, avec tous les essais/erreurs.

Last updated on March 3rd, 2011 : Rails 3 and Bundler are stable, versions of Passenger and REE are up-to-date.

Introduction : Why this advice

The dev team I’m working in is composed of 3 people who use Ruby.
Besides me, who’s is spending the most part of my time on Ruby and became “the one who knows” about this stuff, my co-workers don’t use Ruby the whole day, and use some others languages/frameworks (mostly Objective-C/iPhone and PHP/Symfony).

I’ve chosen to use some quite “bleeding edge” technologies for some reasons (I hope good ones) about performance, features, comfort, … but their beta nature is not very easy to deal with on a daily basis.
It’s especially the case when there are some bugs, frequent changes in APIs, (temporary) incompatibilities, … and when you don’t want to learn and understand every detail at every change. Sometimes, you just need it to work to “get things done”.

I’ll introduce briefly those tools and how they work together with the minimum effort and pain and how to get the most of them.

I emphasize the fact that I’m describing here a development context. I’ve not yet used RVM in production, even if I know that it seems to work really well.

The (not so) usual suspects

Ruby

“Wait, What ? Ruby is not stable yet ?”

Of course it is, but it’s also in a transition from 1.8 to 1.9 (1.9.2 released a few months ago). And there are many implementations (JRuby, Rubinius, …). It is very useful to be able to test your code in those different implementations, with RVM.

RVM – Ruby Version Manager

The main idea behind RVM is to have several different rubies on the same system, in a separate environment from the default ruby installed by the OS vendor, and being able to switch very easily between them.

For each Ruby, it allows to have different groups of gems (Gemsets) to avoid version conflicts between projects.

RVM is rich and powerful, but it introduces some concepts and tools that are not so simple to use in the beginning.
If you’re not completely in phase with it, you can easily use the wrong Ruby and/or Gemset and quickly make quite a mess.

Happily, the documentation is really great and quite up-to-date, and the dev team (@wayneeseguin and his mentee @Sutto) is awesome and always available on IRC.

Ruby on Rails

I won’t describe Rails in details, it’s a well known web development framework written in Ruby.

Since version 3, some parts have stopped being compatible with the previous stable version (2.3), mostly about the “rails” command and the scripts installed in applications. It’ become difficult to use Rails 2 and Rails 3 on the same computer without RVM.

Rails 3 also brings a brand new dependency management tool called Bundler, as a required gem.

Bundler

Bundler is a gem, written in Ruby whose purpose is to manage dependencies in a Ruby project, for example a Rails application.
Much better than the “old” way when dealing with the dependency tree, it is especially excellent to quickly install all the gems required by a project in a restricted area, without interfering with others projects and vice versa.

Its stable version is 1.0 (1.0.10 to be accurate).

Phusion Passenger

Phusion Passenger connects Rack or Rails apps with Apache (or Nginx), allowing to host this kind of Ruby apps almost as easily as PHP scripts/apps.

It is now a stable piece of software, but using it with RVM and Bundler is not always obvious, especially if you want to use a different Gemset (and the gems inside it) for each hosted application.

Issues we had

Those past few months, we mostly had issues with following properly versions changes and dealing with incompatibilities. Although I managed to keep the pace, my co-workers had better things to do than spending hours each week to make all this stuff work. Some changes that I was committing in our repositories were leading to non-working projects on their side or at least some headaches for them. Some hair were pulled, and occasionally, all these beautiful tools were called with improper names ;-)

Recommendations

I’m going to describe the setup from a developer point of view (no production right now), with Mac OS X. It should probably be quite the same with Linux, even if some tools may not come pre-installed, or with different versions, … For Windows, it’s a whole different thing. I have no viable information about what is working or not and this part of the universe is quite hostile with web development (especially Ruby).

Apple has been shipping Mac OS X with Ruby since Leopard (at least). This pre-installed version is not useful here, but it’s good to know that it exists, at least to differentiate from other rubies installed with RVM. Right now, on Mac OS X 10.6.4, Ruby 1.8.7-p174 is installed.

If you start from a state where you’ve never done anything regarding Ruby, gems, … I advise not to instal any gem at all. Everything will be dealt with RVM.

Install RVM

The installation process for RVM is quite simple et well documented. You’d rather read it there than copy/paste from here.

Once RVM is installed, you can install other “rubies”. I suggest using Ruby Enterprise Edition instead of a regular 1.8.7 :

$ rvm install ree

I also suggest to make it the default RVM Ruby and the preferred on for Passenger.

$ rvm use ree --default --passenger

From now on, every new shell will use this version of Ruby and a wrapper script will allow Passenger to use it.

To update RVM itself you just have to

$ rvm get latest

If you want to use the latest from the Git repository instead of the latest release :

$ rvm get head

How to use RVM Gemsets

The Gemset concept

As a reminder, a Gemset is a hermetic environment, dedicated to the installation and use of gems.
Each Ruby installed with RVM has at least 2 Gemsets : default (unnamed in fact), and global. By default, we are in the unnamed Gemset. The global Gemset makes every gem installed in it available for all other Gemsets of the current Ruby. Then you can create as many Gemsets as you like, for example 1 for each development project.

Here is an attempt to represent this visually :

/--------------------------|------------------|------------------\
|           Ruby EE        |     Ruby 1.9.2   |    other Ruby    |
|--------------------------|------------------|------------------|
|           @global        |      @global     |     @global      |
|--------------------------|------------------|------------------|
| @default | @app1 | @appX | @default | @appX | @default | @appX |
\--------------------------|------------------|------------------/

A Gemset by project

For every web sites/apps I’m working on, I create a Gemset. The gems the projects can “see” are isolated from others, it’s like a specific environment for the project. For those managed with Bundler, the interest is slightly smaller, but for others (Rails 2, other frameworks or no framework at all) the interest is considerable.

One of RVM’s features is to recognize the presence of a .rvmrc file in a directory when you enter it (with cd for example). If this file refers to a Ruby and/or a Gemset, RVM makes the switch automatically. Each one of my projects has its .rvmrc file containing at least this line :

rvm --create use default@projectX > /dev/null

In short, it will use the default Ruby (defined earlier, but changeable any time) and the Gemset “projectX” if it exists. If not, it is created right away. Redirecting to /dev/null hides the RVM’s output, otherwise it’s annoying to see it each time you enter such a directory.

Since version 1.0 (released on august 22nd, exactly 1 year after the first commit), each time RVM will find a new .rvmrc file, it will ask if you trust it or not. It’s a security feature.

Gems in the global Gemset

I always install some gems in the global Gemset to have them available, whatever project Gemset I’m in (or if I’m outside any specific project) including the default one.

• passenger
• capistrano + capistrano-ext
• bundler
• git_remote_branch
• awesome_print
• g
• wirble

Those gems will be available in any Gemset inside the Ruby associated with this global Gemset.

Make RVM and Phusion Passenger a happy couple

Usually, Passenger uses a defined ruby binary and the “normal” environment variables to look for gems required by hosted applications.

When you install Passenger, you have to configure the webserver (here Apache, but there is a similar configuration for Nginx) with (at least) those 3 directives :

LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-3.0.4/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-3.0.4
PassengerRuby /usr/bin/ruby1.8

The key point is to tell Passenger to use the right Ruby, where the modules are, … Here is my setup (adapted from RVM documentation) :

LoadModule passenger_module /Users/jlecour/.rvm/gems/ree-1.8.7-2011.03@global/gems/passenger-3.0.4/ext/apache2/mod_passenger.so
PassengerRoot /Users/jlecour/.rvm/gems/ree-1.8.7-2011.03@global/gems/passenger-3.0.4
PassengerRuby /Users/jlecour/.rvm/wrappers/ree-1.8.7-2011.03/ruby

With this, Passenger will use the module from the passenger gem, installed in the global Gemset of the default Ruby and the defined wrapper as a Ruby binary.

OK, but how Passenger will be able to use the right Gemset depending on the application ?

With Passenger >= 2.2.14 and RVM >= 0.1.42 it is possible to use (in Ruby) an API for RVM and adjust the environment variables for the hosted application. It will then know where to look for gems. It’s explained in details by Darcy Laycock (Sutto) in his blog post The Path to Better RVM & Passenger Integration.

Currently, Passenger has a limitation to use only 1 Ruby interpreter. Check out the documentation for more info.

For a Rails 3 application, with Bundler, here is my config/setup_load_paths.rb file :

if ENV['MY_RUBY_HOME'] && ENV['MY_RUBY_HOME'].include?('rvm')
  begin
    rvm_path     = File.dirname(File.dirname(ENV['MY_RUBY_HOME']))
    rvm_lib_path = File.join(rvm_path, 'lib')
    $LOAD_PATH.unshift rvm_lib_path
    require 'rvm'
    RVM.use_from_path! File.dirname(File.dirname(__FILE__))
  rescue LoadError
    # RVM is unavailable at this point.
    raise "RVM ruby lib is currently unavailable."
  end
end

ENV['BUNDLE_GEMFILE'] = File.expand_path('../Gemfile', File.dirname(__FILE__))
require 'bundler/setup'

For a Rails 2 application without Bundler, you just have to delete the last 2 lines.

With this, I can host several Rails 2 and Rails 3 application with Passenger, on the same webserver, without any version conflicts.

Use Bundler for dependencies management

I summarize once again ; Bundler allow to specify which gems (and their versions) required by a project, to install them (with dependency management) and load them exclusively in the project. The result is : easy installation, confidence in the used versions and no conflicts.

If you’ve been using Bundler <= 0.9.6, I strongly recommend to uninstall the previous versions, (unless you explicitly need them), install the pre-release version, then make Bundler re-install the required gems.

$ gem uninstall bundler
$ gem install bundler
$ bundle install

When you bundle install, the Gemfile is processed to build the dependency tree and a Gemfile.lock is created. It is used to know exactly which version of what gems has to be installed.
As long as this file is not modified, the project will only see those gems. It guaranties that the development environment (including other developers) will use the same gems as those for tests, staging, production, …

A developer who wants to update a gem or install a new one has to modify the Gemfile file accordingly then do a bundle install from the root directory of the project (where the Gemfile file is). Then he can commit the changes in the repository for the other developers.

A developer who doesn’t want to manage gem version changes just has to let the Gemfile and Gemfile.lock files like they are. To verify he has every gem the project needs (in the right version), after an update of the codebase, or if the application doesn’t work, he just has to do a bundle install from the root directory of the project. This way, he’s sure to be up-to-date.

Using RVM make all this even easier, faster and reliable. In normal mode, Bundler installs the gems system wide, with all the other gems, but since what he sees as the whole system is only a Gemset, everyone is stays in its yard.
In deployment mode, it installs gems in a cache directory, inside the application. It looks like a Gemset. It is possible to optimize this step with Capistrano

Bundler and Capistrano for an easy depoyment

An application managed with Bundler doesn’t use the usual require methods to load the gems. Bundler takes care of this when the application is initializing. To do this, the gems have to be accessible to Bundler on the application server. We have to check if everything is OK after each deployment and if possible share the gems between releases of the application to avoid unnecessary downloads and disk usage.

Since version 1.0.0.rc.5, Bundler has a Capistrano task (in fact since rc.4 but it had some bugs). You just have to add the line require 'bundler/capistrano' in your deployment recipe (deploy.rb). You can tweak some parameters, but by default, the gems are going into shared/bundle.

Other major packages

For the management of additional packages that Apple does not provide, I usually suggest to use Homebrew. Contrary to MacPorts, it doesn’t install every library or package systematically. If it finds what it needs in the Apple provided libraries (like OpenSSL, …) it’s going to use them instead of downloading/compiling/installing them. It’s faster, more coherent and lighter.

Homebrew also install everything it needs with the user’s permissions, without sudo. It seems a little disturbing for a sysadmin, but in a development context, it makes a lot of sense.

I’ve used Homebrew to install major packages as MySQL, Git, ImageMagick, MongoDB, … and numerous small tools like tree, wget, ack, …

Credits

First, I’d like to thank all the developers and contributors of those awesome tools.

A special thank you for Wayne E Seguin and John Mettraux for the meticulous typo hunting, Thibaut Barrère and Sébastien Gruhier for their support and additional tips.

Dernière mise à jour le 3 mars 2011 : Rails 3 et Bundler sont en version stable, et les versions de Passenger et REE sont actualisées.

Intro : Pourquoi ces conseils

L’équipe de dev dans laquelle je travaille est composée de 3 personnes qui bossent avec Ruby.
À part moi qui ne fait presque que ça et qui suis de fait un peu le “référent” sur ces questions, mes 2 très chers collègues n’utilisent pas Ruby toute la journée et utilisent donc d’autres environnements de travail (Objective-C/iPhone et PHP/Symfony principalement).

J’ai choisi d’utiliser un certain nombre de technologies un peu “bleeding edge” pour des vraies (j’espère des bonnes) raisons de performance, de fonctionnalités, de confort, … mais leur nature “beta” ne les rend pas toujours faciles à comprendre et à manipuler, …
C’est surtout le cas quand il y a des bugs, des changements fréquents de fonctionnement, des incompatibilités (temporaires), … et qu’on n’a pas envie (et c’est normal) de se prendre la tête à tout comprendre. Des fois il faut juste que ça marche.

Je vais donc vous présenter rapidement ces différents outils et comment les faire fonctionner ensemble avec le minimum de souffrance et le maximum d’intérêt.
Je précise que je présente ici un usage de ces outils en environnement de développement. Je n’ai pas utilisé RVM en production, bien que ça soit tout à fait possible, et même conseillé.

Les outils du boucher

Ruby

“Ah bon, Ruby n’est pas encore stable ?”

Si si, mais Ruby est dans une phase de transition entre la version 1.8 et la 1.9 (la 1.9.2 est sortie il y a quelques mois). Et puis il y a plusieurs implémentations (notamment JRuby et Rubinius). Il est donc intéressant de pouvoir facilement tester son code dans ces différentes implémentations, via RVM.

RVM – Ruby Version Manager

Le principe de RVM est de permettre d’installer plusieurs versions de Ruby sur une même machine, dans un environnement hermétique à une éventuelle version installée sur l’OS et de pouvoir basculer de l’une à l’autre facilement.

Il permet aussi, pour chaque Ruby, d’avoir des ensembles de gems bien séparés (Gemset) pour éviter les conflits de versions entre différents projets.

L’outil est très riche et fonctionnellement très puissant, mais il introduit des concepts et des outils pas si simples que ça.
Si on n’est pas complètement en phase avec, on a vite fait de se tromper de version de Ruby et/ou de Gemset.

Heureusement la doc est très bien faite et l’équipe de dev (@wayneeseguin et @Sutto) est super disponible sur IRC.

Ruby on Rails

Je ne présente pas plus en détail Ruby on Rails : c’est un framework de développement d’applications web, écrit en Ruby.

Depuis sa version 3, il apporte énormément de nouveautés, mais aussi certaines incompatibilités par rapport à sa version stable précédente (2.3), surtout au niveau des commandes “rails” et scripts dans les applis. Il n’est donc pas simple du tout d’utiliser Rails 2 et Rails 3 sur une même machine sans utiliser RVM.

Cette version 3 apporte aussi un nouveau système de gestion de dépendances : Bundler, sous forme d’une gem requise.

Bundler

Bundler est une Gem écrite en Ruby, permettant de gérer les dépendances d’un projet écrit en Ruby, par exemple une application Rails.
Beaucoup plus efficace que l’ancien procédé au niveau de la gestion de l’arbre des dépendances il est surtout excellent pour installer rapidement les gems nécessaires à un projet dans un espace limité à ce projet, sans que les éventuelles autres gems installées sur le système ne puisse le perturber.

Sa version stable actuelle est la 1.0 (1.0.10 exactement).

Phusion Passenger

Phusion Passenger sert à connecter des applis Rack ou Rails avec Apache (ou Nginx), permettant d’héberger ces applis presque aussi facilement que des applis/scripts en PHP.

C’est un composant logiciel maintenant bien stable, mais son usage en conjonction avec RVM et Bundler n’est pas toujours évident, surtout si on veut qu’il utilise un Gemset (et les gems qui sont dedans) différent pour chaque applis.

Les difficultés rencontrées

Ces derniers mois, on a surtout rencontré des difficultés avec le suivi des versions et les incompatibilités que ça a révélé. Alors que j’arrivais à peut près à suivre le rythme des changements, … mes collègues avaient mieux à faire. Des modifs que je mettais en commun rendaient certaines fois les projets inutilisables pour les autres, ou en tous cas difficile à remettre en ordre. Ça débouchait sur des cheveux arrachés, des insultes aux outils :-), …

Recommandations

Je vais décrire une situation de poste de développement (donc pas de production), sous Mac OS X. La situation sous Linux sera probablement très proche, à la différence près que les certains composants ne seront pas pré-installés. Pour Windows, c’est tout autre chose, mais je n’ai aucune info fiable sur ce qui marche ou pas dans cet univers assez hostile au développement web (Ruby en particulier).

Apple fourni Ruby en standard depuis Leopard (peut-être même avant). Cette version pré-installée ne nous sera pas utile, mais il est bien de savoir qu’elle existe, ne serait-ce que pour la différencier des autres qui seront installées via RVM. Actuellement, sous Mac OS X 10.6.4, c’est Ruby 1.8.7-p174 qui est installé.

Si on part d’un système “vierge” au niveau de l’utilisation de Ruby, je conseille de n’installer aucune gem particulière et de ne pas toucher à ce qui est présent. On va tout confier à RVM.

Installer RVM

La procédure d’install de RVM est assez simple et bien documentée. Suivez la, c’est plus sûr que si je la recopie ici.

Un fois cette install faite, vous pouvez commencer à installer d’autres “rubies”. Je conseille particulièrement l’utilisation de Ruby Enterprise Edition :

$ rvm install ree

Je conseille aussi d’en faire la version par défaut, et celle pour Passenger.

$ rvm use ree --default --passenger

Dorénavant, tout nouveau shell utilisera cette version de Ruby et un script “wrapper” permettra à Passenger de l’utiliser.

Pour mettre à jour RVM, il suffit de faire :

$ rvm get latest

Pour utiliser la dernière version Git de RVM plutôt que la dernière version publiée :

$ rvm get head

Utilisation des Gemsets de RVM

Concept des Gemsets

Pour rappel, un Gemset est un environnement hermétique dédié à l’installation et l’utilisation de gems.
Chaque version de Ruby connue de RVM dispose d’au moins 2 Gemsets : default (sans nom, en fait), et global. Par défaut on est dans le Gemset sans nom. Le Gemset global permet de rendre disponibles les gems qui y sont installées dans tous les autres Gemsets de la version courante de Ruby.
On peut ensuite créer autant de Gemsets que l’on souhaite, par exemple 1 pour chaque projet de dev.

Voilà une tentative de représentation visuelle :

/--------------------------|------------------|------------------\
|           Ruby EE        |     Ruby 1.9.2   |    autre Ruby    |
|--------------------------|------------------|------------------|
|           @global        |      @global     |     @global      |
|--------------------------|------------------|------------------|
| @default | @app1 | @appX | @default | @appX | @default | @appX |
\--------------------------|------------------|------------------/

Un Gemset par projet

Pour chacun des sites sur lesquels je travaille, je crée donc un Gemset. Ça permet d’isoler les gems qu’il a à disposition et ainsi de simuler un environnement spécifique à ce projet. Pour les projets qui utilisent Bundler l’intérêt est légèrement moindre, mais pour les autres (Rails 2, autres frameworks ou pas de framework) le bénéfice est immédiat.

Une des fonctionnalités de RVM est de reconnaître la présence d’un fichier .rvmrc dans un répertoire lorsqu’on s’y rend (avec cd par exemple). Si ce fichier de config indique qu’il faut choisir un Ruby et un Gemset, il bascule tout seul.
Chacun de mes projets dispose donc d’un fichier .rvmrc contenant au moins cette ligne :

rvm --create use default@projetX > /dev/null

En résumé, il va utiliser la version par défaut de Ruby (définie plus haut, mais modifiable à tout instant) et le Gemset “projetX” s’il existe. S’il n’existe pas, il est créé automatiquement. Le renvoi sur /dev/null permet que cette opération ne génère aucune sortie, ce qui est le cas sinon et c’est vite casse-pieds lorsqu’on navigue beaucoup via le terminal.

Depuis la version 1.0 (sortie le 22 août, 1 an exactement après le premier commit), RVM va demander confirmation la première fois qu’il rencontre un fichier .rvmrc dans un répertoire. C’est une précaution de sécurité.

Des gems dans le Gemset global

J’installe un certains nombre de gems dans le Gemset global pour les avoir toujours sous la main, quelque soit le projet dans lequel je travail ou si je suis simplement dans un shell hors projet.

• passenger
• capistrano + capistrano-ext
• bundler
• git_remote_branch
• awesome_print
• wirble
• g

Ces gems seront donc dispo pour tous les Gemsets de la version de Ruby associée au Gemset global en cours.

Couplage harmonieux de RVM et Phusion Passenger

Dans son fonctionnement normal, Passenger utilise une version définie de Ruby et les variables d’environnement “normales” pour savoir où trouver les gems, …

Lorsqu’on install Passenger, on doit indiquer au serveur web (ici c’est Apache mais il y a une variante pour Nginx) ces 3 directives :

LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-3.0.4/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-3.0.4
PassengerRuby /usr/bin/ruby1.8

La clé est d’indiquer à Passenger la bonne version de Ruby et l’emplacement des modules, … Voilà ma propre config :

LoadModule passenger_module /Users/jlecour/.rvm/gems/ree-1.8.7-2011.03@global/gems/passenger-3.0.4/ext/apache2/mod_passenger.so
PassengerRoot /Users/jlecour/.rvm/gems/ree-1.8.7-2011.03@global/gems/passenger-3.0.4
PassengerRuby /Users/jlecour/.rvm/wrappers/ree-1.8.7-2011.03/ruby

En l’état, Passenger utilisera donc le module présent dans la gem installée dans le Gemset global et la version de Ruby définie par le wrapper passenge_ruby.

C’est bien, mais comment va-t-il utiliser le bon Gemset selon l’application ?

Avec un Passenger >= 2.2.14 et RVM >= 0.1.42 il est désormais possible d’utiliser (en Ruby) une API interne à RVM et forcer les variables d’environnement pour l’application lancée et qu’elle sache où chercher les gems dont elle a besoin. Le procédé est détaillé dans l’article The Path to Better RVM & Passenger Integration.
En résumé, au chargement de l’application Ruby, on demande à RVM quelques sont les variables à utiliser.

Pour le moment, Passenger est limité à un seul interprêteur Ruby. Voir la doc pour plus d’info.

Pour une appli en Rails 3, avec Bundler, voilà mon fichier config/setup_load_paths.rb :

if ENV['MY_RUBY_HOME'] && ENV['MY_RUBY_HOME'].include?('rvm')
  begin
    rvm_path     = File.dirname(File.dirname(ENV['MY_RUBY_HOME']))
    rvm_lib_path = File.join(rvm_path, 'lib')
    $LOAD_PATH.unshift rvm_lib_path
    require 'rvm'
    RVM.use_from_path! File.dirname(File.dirname(__FILE__))
  rescue LoadError
    # RVM is unavailable at this point.
    raise "RVM ruby lib is currently unavailable."
  end
end

ENV['BUNDLE_GEMFILE'] = File.expand_path('../Gemfile', File.dirname(__FILE__))
require 'bundler/setup'

Pour une application Rails, sans Bundler, il suffit de supprimer les 2 dernières lignes.

De cette manière, j’arrive à héberger avec Passenger des applis Rails 2, Rails 3 et Rack sur le même serveur web, sans conflit de version.

Utiliser Bundler pour la gestion des dépendances

Je résume une fois de plus ; Bundler permet de spécifier les gems (et leur version) nécessaires à un projet, de les installer (avec prise en charge des dépendances) et de ne “proposer” au projet en question que ces gems là. Le résultat est donc : facilité d’installation, confiance dans les versions utilisées, absence de conflits.

Si vous avez utilisé une version de Bundler <= 0.9.6, je ne peux que vous conseiller de désinstaller les version actuelles (sauf si vous en avez explicitement besoin), installer la version 1.0.rc puis recalculer les dépendances.

$ gem uninstall bundler
$ gem install bundler
$ bundle install

La version 1.0 (même depuis sa première beta) a apporté de gros changement, dont certains sont incompatibles, mais elle simplifie la gestion des déploiements en production, …

Lorsque dans un terminal, à la racine d’un projet géré avec Bundler, on fait un bundle install, le fichier de config Gemfile est analysé pour déterminer l’arbre des dépendances et un fichier Gemfile.lock est créé. Il est ensuite utilisé pour connaître l’exacte version de chaque gem à installer/utiliser.
Tant que ce fichier n’est pas modifié, le projet d’utilisera que ces gems là, ce qui garanti une cohérence entre l’environnement de développement (y compris d’un développeur à l’autre) et ceux de test, pre-production, production, …

Un développeur qui souhaite mettre à jour une gem ou en installer une nouvelle doit modifier le fichier Gemfile en conséquence, puis faire un bundle install. Il peut enfin versionner ces changements pour les rendre disponibles aux autres développeurs.

Un développeur qui ne veut pas gérer les changements de version de gems du projet en cours ne doit juste pas toucher aux fichiers Gemfile et Gemfile.lock. Pour s’assurer qu’il dispose en local des gems nécessaires à l’exécution de l’application ou bien si après une mise à jour du code il rencontre un “plantage” indiquant une erreur de gem, le 1er réflexe doit être de faire un bundle install depuis la racine du projet. Ainsi il s’assure d’être à jour au niveau des gems et de leur version.

L’utilisation de RVM rend ces processus encore plus faciles, rapides et fiables. En effet en mode normal, Bundler va installer au niveau système les gems nécessaires, mais comme le niveau système qu’il voit est en fait un Gemset, il ne pollue pas les autres projets.
En mode déploiement, il installe les gems dans un dossier de cache au sein de l’application, ce qui revient à peut près au même qu’un Gemset. Il est possible d’optimiser cette phase avec Capistrano.

Bundler et Capistrano pour un déploiement rapide et facile

Une appli gérée avec Bundler n’utilise plus les mécanismes classiques de require pour charger ses gems, c’est Bundler qui s’en charge à l’initialisation de l’appli. Il faut donc que les gems soient installées et accessibles à Bundler sur le serveur d’application. Il faut donc vérifier que tout est OK après chaque déploiement, et si possible mutualiser les gems d’une fois sur l’autre pour éviter des téléchargements et une consommation inutiles.

Depuis la version 1.0.0.rc.5, Bundler dispose d’une tache pour Capistrano (en réalité c’est depuis la rc.4 mais elle contenait des bugs). Il suffit d’ajouter require 'bundler/capistrano' dans sa recette de déploiement (deploy.rb). On peut éventuellement spécifier l’emplacement d’installation des gems, mais par défaut, c’est dans shared/bundle.

Autres paquets majeurs

Pour la gestion courante des paquets additionnels non fournis par Apple, je conseille d’une manière générale l’utilisation de Homebrew. Contrairement à MacPorts, il ne réinstalle pas toutes les dépendances systématiquement. S’il trouve son bonheur dans les paquets et librairies installés par Apple, il va les utiliser. Ça assure une plus grande cohérence, rapidité d’install et légèreté d’ensemble.

Homebrew installe aussi tout ce qui lui est nécessaire dans l’environnement utilisateur, sans nécessité d’utiliser sudo. C’est un peu déroutant pour un sysadmin, mais dans un contexte de développement, c’est plus pratique et plus simple.

J’ai utilisé Homebrew sur mon Mac pour installer MySQL, Git, ImageMagick, MongoDB, … et nombre de petits outils tels que tree, wget, ack, …, avec beaucoup de satisfaction.

Crédits

En priorité, je souhaite remercier les développeurs de ces outils géniaux et l’armée de contributeurs qui a participé.

Merci à Wayne E Seguin et John Mettraux pour une méticuleuse relecture, Thibaut Barrère et Sébastien Gruhier pour leur soutien et des astuces additionnelles

Pour ceux qui auraient raté un wagon, l’idée vient de là.

Cette fois, nous allons nous aventurer sur les terres un peu plus techniques de Git, le célèbre système de contrôle de version pour les développeurs (et pas que).

Quel livre pour cette fois ?

Le livre s’appelle Pro Git, écrit par Scott Chacon et édité par APress. On le trouve en version papier ou gratuitement en html. Les sources sont mêmes disponibles sur Github.

Pro Git détaille le fonctionnement de Git, depuis les concepts de bases du versionning jusqu’aux dernières subtilités d’utilisation de ce formidable outil qui change la vie de ceux qui l’utilisent.

C’est un livre écrit par une des personnes qui connaissent le mieux Git — Scott Chacon — guru de Git chez Github. Ses talents de pédagogue et la qualité du contenu font de Progit un livre clé pour appréhender le vaste sujet du contrôle de version. Les chapitres sont focalisés et concis, illustrés de séquences de lignes de commande et d’illustrations.

Même si je conseille vivement la lecture intégrale du livre, nous avons choisi d’étudier en particulier le chapitre 3 : Git Branching.

Où et quand ?

Le rendez-vous est à La Bo[a]te, le vendredi 4 juin à 17h30

Utilisez les commentaires pour donner votre avis, poser des questions, … N’hésitez pas.

Ceci est la suite de l’article d’annonce du premier "épisode" du club de lecture dans lequel vous trouverez les infos générales.

D’après les commentaires et avis donnés ces derniers jours, on a donc fixé la date et le sujet de lecture/discussion

• Date : mercredi 12 mai, à La Bo[a]te, à partir de 17h30
• Sujet : Getting Real par 37signals

Je rappelle ce que  disais dans mon article d’annonce :

Même si je conseille évidemment à tout le monde de lire la totalité du bouquin, je propose qu’on se focalise sur les chapitres « Priorities » et « Feature Selection » (pages 37 à 58).

Outre les versions PDF et papier qui sont payantes, il existe une version gratuite en ligne. 
http://gettingreal.37signals.com/

Il est important que chacun prenne le peu de temps nécessaire pour lire au moins ces 2 chapitres, pour qu’on puisse avoir une vraie discussion active. Ça n’empêche par contre personne de venir en curieux pour juste regarder comment ça se passe.

Ceux qui me connaissent peuvent être étonnés.

"Qu’est-ce qu’un développeur Ruby, si passionné par ce langage peut bien aller faire chez des pythonistes ?"

J’avoue que je me suis moi aussi posé la question, mais je ne regrette pas de l’avoir fait.

Des gens bien

J’avais déjà lu sur le net que la communauté des pythonistes est accueillante, pas sectaire, … et j’ai clairement pu le vérifier. Déjà j’étais pas inscrit, c’était complet, et on m’a quand même fait une place.

Le samedi après-midi, je me suis plutôt fait discret, du moins par rapport à Ruby. Je ne voulais pas avoir l’air du cow-boy qui vient pour foutre la merde dans un saloon où on ne le connaît pas. J’ai posé quelques questions et fait quelques remarques, mais sur des sujets que je connais, sans dire "oui en Python, mais en Ruby c’est mieux".

Quand il a été question de fixer le programme des lightning-talks, je me suis proposé, pour rigoler, de faire une présentation Ruby, et on m’a pris au sérieux et fait une place parmi les autres.

J’ai donc préparé un peu en urgence une mini présentation (4 minutes) de Rails 3, pour rester dans l’univers framework plutôt que langage.

Je pensais me faire siffler, … mais en fait il semblerait que ça ait intéressé du monde et même évoqué des curiosités et des envies de voir plus loin, pour certains. Il paraît que j’ai même un créneau pour une présentation complète pour l’édition 2011. Attention, je suis pas du genre à me défiler ;-)

Tout le temps que j’ai passé parmi cette bande de geeks, j’ai plutôt eu l’impression d’être un cousin éloigné, mais avec qui on a beaucoup de choses en commun.

La technologie

Pendant les moments de pause, et au repas, … j’ai pu discuter de manière très ouverte et détendue avec pas mal de monde, tous des gens bien, curieux, ouverts, … J’ai pu parler de Ruby, de ses forces, de ses quelques faiblesses, de son écosystème. J’au aussi pu entendre plein de choses intéressantes sur Python et Django. On a aussi pu parler abondamment de versionning en général et de Git en particulier.

Je le savais déjà, mais j’ai pu le vérifier, il y a finalement beaucoup de similitudes entre ces 2 mondes.

Les sujets des conférences étaient appliqués à Django, mais certains pouvaient abstraits à d’autres contextes. J’ai donc appris certains trucs, mais rien de complètement nouveau. Ça n’est pas le fait d’être venu là qui me fait changer d’avis sur Python et Django, mais au moins j’en ai une idée plus précise.

Conclusion

Ce que je retient c’est le plaisir d’avoir passé un moment très geek, avec des gens sympa, d’avoir pu parler de ma passion et écouter celle des autres, confronter des convictions, et s’ouvrir l’esprit à des choses nouvelles.

Rendez-vous donc l’année prochaine pour un plat de résistance plus copieux autour de Ruby et de Rails.

D’ici là, et pour ceux qui sont ou viennent à Marseille, il y a les réunions du PLUG, tous les mois, pour discuter de développement, de langages, frameworks, infrastructures, …

La plupart des questions que je posais lors de l’exposé de mon idée n’a pas trouvé de réponse à cette heure, mais c’est pas grave, on va se lancer avec le bon sens comme point de départ — enfin le mien donc j’espère que c’est le bon.

Quelle date ?

Je propose donc le vendredi 30 avril à partir de 17h30, jusqu’à 18h30-19h.

Ça n’est qu’une proposition et il y a finalement peu de contraintes sur la date, à part l’idée à laquelle je tiens, qu’il faut que ne ça soit pas sur du temps personnel, mais plus sur du temps de boulot. Je vous renvoie à mes arguments sur la question si besoin.

Si vous êtes intéressé(e) mais que la date pose un problème, dites le en commentaire, on trouvera ce qui convient le mieux.

Quel livre ?

J’ai bien dans l’idée d’aborder des sujets assez avancés : certaines techniques de programmation, d’organisation des projets, … mais ça me paraissait risqué de partir trop vite, trop fort. Il suffit que le sujet soit trop axé sur tel ou tel langage ou approche pour que les timides soient refroidis et que la sauce ne prenne pas.

J’ai donc cherché un sujet qui concerne tout le public, à savoir les geeks intéressés à découvrir de nouvelles pratiques : innovation techno, optimisation des méthodes et perfectionnement des outils.

J’ai dit que ça n’était pas "mon" club de lecture, même si j’en suis à l’origine, donc je propose 2 livres, bien différents. Ceux qui souhaiteraient participer n’ont qu’à donner leur avis, on choisira en fonction.

Getting Real par 37signals

Getting Real expose les concepts de l’équipe de 37signals sur le travail d’une équipe qui produit une application web. De l’émergence de l’idée, jusqu’au marketing et support client en passant par la conception, le financement, la création des interfaces, le développement du code et l’organisation de l’équipe qui porte le projet.

C’est un ensemble de très courts essais, illustrant chacun une idée simple, organisés en chapitres cohérents. Ça se lit très vite (160 pages de 200/300 mots chacune). Il m’a suffit de 4 à 5 heures de lecture pour le boucler, et je ne lis pas vite.

Même si je conseille évidemment à tout le monde de lire la totalité du bouquin, je propose qu’on se focalise sur les chapitres "Priorities" et "Feature Selection" (pages 37 à 58).

Outre les versions PDF et papier qui sont payantes, il existe une version gratuite en ligne. 
http://gettingreal.37signals.com/

Progit par Scott Chacon

Progit détaille le fonctionnement de Git, un système de contrôle de version, depuis les concepts de bases du versionning jusqu’aux dernières subtilités d’utilisation de ce formidable outil qui change la vie de ceux qui l’utilisent.

C’est un livre écrit par une des personnes qui connaissent le mieux Git — Scott Chacon — guru de Git chez Github. Ses talents de pédagogue et la qualité du contenu font de Progit un livre clé pour appréhender le vaste sujet du contrôle de version. Les chapitres sont focalisés et concis, illustrés de séquences de lignes de commande et d’illustrations.

Je propose de se focaliser sur un seul chapitre à choisir entre "Git Branching" et "Distributed Git". Les deux sujets sont très différents et méritent chacun une pleine discussion.

Le livre existe en version PDF et papier chez Apress, mais il est également disponible gratuitement en ligne (HTML ou sources). 
http://progit.org/

Au Choix