Akei Blog

Scrape and test any webpage using PhantomJS

2011-08-27T00:00:00+02:00

Have you ever tried to scrape or harvest data from an existing website — I mean, even ajax-bloated ones? Did you ever attempt to test javascript-dependent interactions within a Web application you built? Well, if you answered yes to one of the questions above, you might be interested in PhantomJS.

PhantomJS is a headless WebKit with JavaScript API. By headless, they mean you can script a real Webkit based browser with no need for a full graphical interface installed.

Installation

On OSX, installation can be achieved using homebrew (note that XCode must be installed on your machine):

$ brew install phantomjs

It can take a bit of time for the binaries to be built, especially because of their dependency to Qt4. When it's done, you can test it this way:

$ phantomjs
Usage: phantomjs [options] script.[js|coffee] [script argument [script argument ...]]
Options:
    --load-images=[yes|no]             Load all inlined images (default is 'yes').
    --load-plugins=[yes|no]            Load all plugins (i.e. 'Flash', 'Silverlight', ...) (default is 'no').
    --proxy=address:port               Set the network proxy.
    --disk-cache=[yes|no]              Enable disk cache (at desktop services cache storage location, default is 'no').
    --ignore-ssl-errors=[yes|no]       Ignore SSL errors (i.e. expired or self-signed certificate errors).

Installation instructions for other platforms and alternative methods can be found on the PhantomJS project wiki.

As a side note, there's also a Python implementation of PhantomJS, PyPhantomJS, which adds plugins support! Also, I've found myself having no segfault using the Python version while the standard one is a bit more unstable on my box (no troll please).

To install PyPhantomJS, let's use pip:

$ pip install PyPhantomJS

The PyPhantomJS executable is named — surprise — pyphantomjs:

$ pyphantomjs
usage: pyphantomjs [options] script.[js|coffee] [script argument [script argument ...]]
Minimalistic headless WebKit-based JavaScript-driven tool
positional arguments:
  script.[js|coffee]    The script to execute, and any args to pass to it
optional arguments:
  -h, --help            show this help message and exit
  --disk-cache {yes,no}
                        Enable disk cache (default: no)
  --ignore-ssl-errors {yes,no}
                        Ignore SSL errors (default: no)
  --load-images {yes,no}
                        Load all inlined images (default: yes)
  --load-plugins {yes,no}
                        Load all plugins (i.e. Flash, Silverlight, ...) (default: no)
  --proxy address:port  Set the network proxy
  -v, --verbose         Show verbose debug messages
  --version             show this program's version and license

Usage of the two versions is exactly the same.

Basic usage

PhantomJS scripts can be written in standard JavaScript or in CoffeeScript. Mainly matter of taste here, but CoffeeScript syntax looks really interesting.

So let's write our first script, we want to retrieve the weather forecast for a given city using Google:

// script: meteo.js
var page = new WebPage()
, output = { errors: [], results: null };
if (phantom.args.length == 0) {
    console.log('You must specify a city, eg. "Paris, France"');
    phantom.exit(1);
}
page.open('http://www.google.fr/search?q=meteo+' + phantom.args[0], function (status) {
    if (status !== 'success') {
        output.errors.push('Unable to access network');
    } else {
        var cells = page.evaluate(function(){
            try {
                var cells = document.querySelectorAll('.tpo tr tr')[4].querySelectorAll('td');
                return Array.prototype.map.call(cells, function(cell) {
                    return cell.innerText.replace(/[^0-9]/g, '');
                });
            } catch (e) {
                return [];
            }
        });
        if (!cells || !cells.length > 0) {
            output.errors.push('No valid meteo data found');
        } else {
            output.results = {
                city: phantom.args[0],
                today: {
                    afternoon: cells[1],
                    morning:   cells[2],
                },
                tomorrow: {
                    afternoon: cells[3],
                    morning:   cells[4],
                }
            };
        }
        console.log(JSON.stringify(output, null, '    '));
    }
    phantom.exit();
});

Notice we use the phantom.args Array which contains the parameters passed to the script.

The main magic happens in the page.evaluate() method, we pass it a JavaScript function which will be evaluated within the retrieved page document environment. It's a kind of non-persistent XSS injection just to help you to operate on the page contents =)

Now it's time to launch the script to see how it goes:

$ phantomjs meteo.js "Montpellier, France"
{
    "errors": [],
    "results": {
        "city": "Montpellier, France",
        "today": {
            "afternoon": "29",
            "morning": "17"
        },
        "tomorrow": {
            "afternoon": "28",
            "morning": "17"
        }
    }
}

Now with an invalid city name:

$ phantomjs meteo.js "Unexistent City"
{
    "errors": [
        "No valid meteo data found"
    ],
    "results": null
}

Let's try with another city, an existing one this time:

$ phantomjs meteo.js "Paris, France"
{
    "errors": [],
    "results": {
        "city": "Paris, France",
        "today": {
            "afternoon": "21",
            "morning": "11"
        },
        "tomorrow": {
            "afternoon": "21",
            "morning": "11"
        }
    }
}

As a side note and in case you were wondering, you now understand a bit more why I moved to Montpellier ;)

I CAN HAZ SCREENSHOTS

PhantomJS also allows some nice tricks like injecting scripts to the remote page, very useful when a remote website doesn't ship with your favorite framework (eg. jQuery)… or can render a PNG image of a captured area of the webpage. The example below saves a capture of the weather forecast area:

// script: meteoclip.js
var page = new WebPage();
page.open('http://www.google.fr/search?q=meteo+montpellier,+France', function (status) {
    if (status !== 'success') {
        output.error = 'Unable to access network';
    } else {
        page.clipRect = {
            top: 127,
            left: 170,
            width: 400,
            height: 114
        }
        page.render('meteo.png');
        console.log('Capture saved');
    }
    phantom.exit();
});

Running the meteoclip.js script will get yourself this fancy image stored in meteo.jpg:

There are tons of other cool topics to cover about PhantomJS, like navigation handling, automated logging in, external resources retrieving, functional testing, code organization… so I'll maybe post a bit more about it soon, who knows!

Une autre façon de gérer ses settings d'application Django

2011-04-13T00:00:00+02:00

Je travaille actuellement sur une application Django que je compte publier sous licence libre, et je suis confronté au problème classique de l'exposition de la configuration au développeur via les settings de son propre projet.

Classiquement, on a tendance à proposer les settings "à plat", dans le module settings.py du projet :

# settings.py
MY_APP_NAME_FOO = 42
MY_APP_NAME_ENABLE_CHUCK_NORRIZ_MODE = True

Et donc depuis votre appli, vous pouvez récupérer les settings utilisateur de cette façon, en leur assignant une valeur par défaut s'ils ne sont pas déclarés :

# apps/myapp/foo.py
from django.conf import settings

FOO = getattr(settings, 'MY_APP_NAME_FOO', 42)
ENABLE_CHUCK_NORRIZ_MODE = getattr(settings, 'MY_APP_NAME_ENABLE_CHUCK_NORRIZ_MODE', False)

Simple, pratique, suffisant me direz vous. Oui, mais bon, c'est un petit peu verbeux à mon sens, et pas toujours souple pour gérer un catalogue de settings ainsi que leur surcharge. Et puis j'ai l'impression en préfixant systématiquement ces noms de variables de faire insulte à cette merveilleuse fonctionnalité qu'on appelle la gestion des espaces de noms (voire de refaire du PHP < 5.3, ce qui provoque chez moi des bouffées d'angoisse et entame un processus de décapilation douloureux, mais je m'égare).

Qui plus est, personnellement en temps que développeur, j'aurai tendance à préférer gérer les settings correspondant à une application dans un dictionnaire dédié, un peu comme ce que propose la django-debug-toolbar.

Par exemple, en reprenant l'exemple de code initial ou seul le setting ENABLE_CHUCK_NORRIZ_MODE est finalement surchargé :

# settings.py
MY_APP_CONFIG = {
    'ENABLE_CHUCK_NORRIZ_MODE': True,
}

J'ai donc trouvé un moyen assez simple de proposer cette fonctionnalité. Dans le fichier __init__.py de votre module d'application, ajoutez le code suivant :

# apps/my_app/__init__.py
from django.conf import settings

app_settings = dict({
    'FOO': 42,
    'ENABLE_CHUCK_NORRIZ_MODE': False,
}, **getattr(settings, 'MY_APP_CONFIG', {}))

Vous constaterez qu'on fusionne bêtement les settings par défaut et ceux de l'utilisateur qui auront la priorité de surcharge. Ainsi, partout depuis votre application, vous pourrez accéder à ce dictionnaire de settings de cette façon :

# apps/my_app/utils.py
from . import app_settings

if app_settings.get('ENABLE_CHUCK_NORRIZ_MODE'):
    print 'Chuck Norriz is watching you'
else:
    print 'Dance dance, little lamb'

Et bien entendu, pour importer les settings de l'application depuis n'importe où (sous réserve que le module de l'application soit dans votre PYTHON_PATH) :

# foo/bar.py
from my_app import app_settings

print app_settings.get('FOO') # 42

Merci de votre attention, et à bientôt pour de nouvelle aventures.

Creating a Custom Panel for the Django Debug Toolbar

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

Sometimes you work on stuff you don't really control, eg. when interacting with some mysterious SOAP server accross the Internets, and you'd appreciate a little help from the Django ecosystem to ease debugging.

That's — you guessed it — my case currently, and I really appreciated being able to create my own custom panel for adding specific debugging capabilities to the awesome Django Debug Toolbar.

Here's how I did, learning mainly from the code of the panels shipping with the DJT. I'm supposing you have installed and configured the DJT in your project already.

First of all, create a panels.py module within one of your app (or wherever you want as it's in your python path) and create a DebugPanel derivated class, like this:

from debug_toolbar.panels import DebugPanel
from django.template.loader import render_to_string
from django.utils.translation import ugettext_lazy as _

class MyUsefulDebugPanel(DebugPanel):
    name = 'MyUseful'
    has_content = True

    def nav_title(self):
        return _('Useful Infos')

    def title(self):
        return _('My Useful Debug Panel')

    def url(self):
        return ''

    def content(self):
        context = self.context.copy()
        context.update({
            'infos': [
                {'plop': 'plip'},
                {'plop': 'plup'},
            ],
        })
        return render_to_string('panels/my_useful_panel.html', context)

The debug panel class methods and code should be self-explanatory enough. Just note you have to create a template, here panels/my_useful_panel.html to be stored in your project templates directory, with this kind of contents:

<p>Hey, these are useful informations, I swear:</p>
<ul>
{% for info in infos %}
    <li>Plop is {{ info.plop}}</li>
{% endfor %}
</ul>

Now you have to register the new panel by adding its path to the DEBUG_TOOLBAR_PANELS tuple, in your settings.py (create it if it's not there):

DEBUG_TOOLBAR_PANELS = (
    'debug_toolbar.panels.version.VersionDebugPanel',
    'debug_toolbar.panels.timer.TimerDebugPanel',
    'debug_toolbar.panels.settings_vars.SettingsVarsDebugPanel',
    'debug_toolbar.panels.headers.HeaderDebugPanel',
    'debug_toolbar.panels.request_vars.RequestVarsDebugPanel',
    'debug_toolbar.panels.template.TemplateDebugPanel',
    'debug_toolbar.panels.sql.SQLDebugPanel',
    'debug_toolbar.panels.signals.SignalDebugPanel',
    'debug_toolbar.panels.logger.LoggingPanel',
    'my_app_name.panels.MyUsefulDebugPanel',
)

Of course it's up to you to put really useful informations there, but here's the result, tadaa:

Thanks for reading, happy ponying.

Du Sud avec du Web dedans, et réciproquement

2011-01-28T00:00:00+01:00

Ceux qui me connaissent le savent, je suis partisan d'une gestion intransigeante de la qualité sur le Web, et suis donc — comme souvent dans ce cas — un grand fan du cycle de conférences Paris Web qui a lieu tous les ans en octobre à Paris. C'est l'occasion d'y faire un état des lieux des meilleurs pratiques, d'attraper un rhume, de découvrir de nouvelles techniques, de profiter des joies du métro, ou de rafraîchir ses connaissances (au propre comme au figuré). Surtout, c'est l'occasion d'échanger avec d'autres passionnés de la profession autour de breuvages houblonnés le soir venu en refaisant le Web jusqu'à plus d'heure ni soif.

Mais voila, Paris, c'est loin. Et Paris, ça a tendance à un peu trop vouloir centraliser tout ce qui remue à mon goût. Je m'en rends forcément mieux compte depuis que j'ai déménagé à Montpellier il y a un an et demi (fichtre comme le temps passe). Et surtout, je constate que la région dans laquelle je vis est immensément riche de passion et de compétences autour de ce noble medium qui est le nôtre. Des gens bien, un peu partout autour de moi, qui n'ont pas toujours la possibilité de se déplacer jusqu'à la capitale, de s'y loger, de s'y nourrir, de s'y acheter le nombre d'écharpes nécessaires pour survivre, etc.

Aussi, durant le trajet en voiture qui nous conduisait au dernier Paris Web moi et mes compagnons de route, nous avons une idée assez folle : organiser un évènement du même type que Paris Web, mais dans le sud. C'est à dire plus proche de nous géographiquement et assurant une meilleure compatibilité feinéantique et calorifère. Ainsi naquit l'idée d'un SubWeb.

Après quelques tergiversations, tatônements, études de terrain et autres défrichements des sols argileux du Gard, nous avons fixé la date et le lieu de la première édition de SubWeb qui se tiendra donc le vendredi 27 mai 2011, à l'École des Mines d'Alès de Nîmes.

À toutes fins utiles et pour éviter d'éventuelles déconvenues, il est cependant important de noter que SudWeb ne sera pas un Paris Web transposé plus au sud. Personnellement, j'ai toujours considéré un peu dommage de ne se focaliser que sur l'aspect frontend du Web — certes plein d'enjeux à ne surtout pas négliger — alors que d'autres aspects majeurs, bien que moins visibles des utilisateurs, méritent tout autant notre attention :

les aspects backend : architecture technique, hébergement, plateformes, langages, serveur, etc. ;
les aspects et enjeux méthodologiques de la gestion technique — voire commerciale — d'un projet Web ;
les valeurs métier liées au Web et la production de valeur ajoutée d'un point de vue humain et non plus uniquement mercantile ;
les aspects métier à proprement parler, et les enjeux qui accompagnent le changement dans les pratiques et les usages associés au Web.

Tout un programme ! En parlant de programme, un appel à conférence est lancé jusqu'au 7 février inclus, et n'attend que votre proposition d'intervention si vous souhaitez aussi partager un bon moment et votre expérience de faiseur de Web.

Le processus d'inscription, les tarifs et modalités, quand à eux, vous seront communiqués dès que les conditions normales de température et de pression seront optimales, stay tuned ;-)

EDIT : Les inscriptions sont désormais ouvertes, et les tarifs connus :

135 € pour la journée, repas inclus
15 € supplémentaires vous seront demandés si vous désirez participez à la soirée communautaire le soir même

Si vous êtes chômeur ou étudiant, Akei a le plaisir de sponsoriser votre place et prend en charge 45€ sur le prix du ticket d'entrée pour la journée de conférence, ramenant le prix à 90 € au lieu de 135 €.

Enfin, sachez qu'un financement du prix du ticket d'entrée est possible dans le cadre du Droit Individuel à la Formation (DIF).

Ne tardez pas pour commander votre place en ligne, la clôture des inscriptions est prévue pour le 2 mai.

Enabling tab completion in OS X Python interactive interpreter

2010-12-29T00:00:00+01:00

Python is awesome, and so is its native interactive interpreter. I discovered today that it can even provide autocompletion using a very simple trick:

# in your ~/.profile
export PYTHONSTARTUP=$HOME/.pythonrc.py

# in a new ~/.pythonrc.py file
try:
    import readline
except ImportError:
    print("Module readline not available.")
else:
    import rlcompleter
    readline.parse_and_bind("tab: complete")

Note: Don't forget to source your .profile with $ source ~/.profile.

Magic? Well if like me you're running Mac OS X, it won't work, no autocompletion, nada. OS X seems to ship with a very poor (and obsolete) python, and no readline implementation — which is mandatory to achieve our purpose. I even tried to install readline by its own, but it won't solve the problem.

So while being at tweaking up my python setup, let me get rid of the Apple stuff and install a fresh version of python using Homebrew, a great package manager for OSX:

$ brew install readline python

Tadaa! Now you get autocompletion, plus a shiny python 2.7.1 (you could also install latest python3 running brew install python3 by the way).

As a side note, if you work with virtualenvs like me, creating a new env will now involve specifying which python you want to use:

$ mkvirtualenv -p /usr/local/Cellar/python/2.7.1/bin/python \
    --no-site-packages `pwd`/env

That's all folks.

Install PIL within a virtualenv on Snow Leopard

2010-12-03T00:00:00+01:00

As a personal reminder, here's how to install PIL with jpeg and freetype support in a Python virtualenv with a little help from Homebrew:

$ brew install jpeg
$ wget http://mirrors.fe.up.pt/pub/nongnu/freetype/freetype-2.4.4.tar.gz
$ tar xvzf freetype-2.4.4.tar.gz && cd freetype-2.4.4
$ ./configure && make && sudo make install
$ cd .. && rm -rf freetype-2.4.4*
$ mkvirtualenv fubar --no-site-packages
(fubar)$ pip install PIL

You should obtain something like this at the end of the installation process:

--------------------------------------------------------------------
PIL 1.1.7 SETUP SUMMARY
--------------------------------------------------------------------
version       1.1.7
platform      darwin 2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
              [GCC 4.2.1 (Apple Inc. build 5646)]
--------------------------------------------------------------------
--- TKINTER support available
--- JPEG support available
--- ZLIB (PNG/ZIP) support available
--- FREETYPE2 support available
*** LITTLECMS support not available
--------------------------------------------------------------------

That's all for today folks, thanks for your attention.

EDIT: If you want little-cms support, just run:

$ brew install little-cms
(fubar)$ pip install PIL

Choisir son métier, arrêter de le (faire) subir

2010-10-27T00:00:00+02:00

Je viens de finir la lecture de l'excellent billet de Thibault, « Dialogue avec un client ». Ce billet présente point pour point ma vision de ce qu'est une collaboration efficace autour d'un projet informatique ; je n'y apprends rien de vraiment nouveau (ayant partiellement nourri la conversation qu'il y relate), mais je suis ravi de voir que je ne suis pas le seul à partager le sentiment que la collaboration est vraiment à réinventer dans ce métier.

Ce qui me chagrine plus en revanche, c'est la lecture de certains commentaires, relativement fatalistes et désabusés ; je ne resiste pas à la tentation d'en commenter certains.

La métaphore du concessionnaire automobile

Le client qui sait exactement ce qu’il veut voudra acheter son site comme une voiture.

Il veut choisir les options et la peinture tout de suite et connaitre l’enveloppe budgétaire dès le début.

Nous y revoila, la fameuse métaphore du concessionnaire automobile, ça faisait longtemps. Comment comparer le développement d'un produit sur-mesures à l'achat d'un produit de type industriel ?

funny car, par mayme

Je peux comprendre que certains, dans notre secteur, s'emploient à minimiser les coûts de production en génériquant des sites vitrines à base de CMS — voire de frameworks surpluginisés — généralement open-source, mais quand vous avez un client qui arrive avec un cahier-décharge de quelques lignes du type :

Mâcon, le 27 juin,

Monsieur,

Veuillez trouver ci-après notre cahier des charges pour notre projet d'application Internet :

Un réseau social orienté vente de clous rouillés online, sans oublier les groupes géolocalisés d'amateurs et de collectionneurs

Une place de marché permettant d'échanger des clous rouillés, avec des graphiques permettant de suivre les enchères en temps réel

Fournir un extranet fournisseurs leur permettant de saisir leurs prix et leurs quantités

En option l'intégration d'un service de location de marteaux d'occasion avec un partenaire qu'il nous reste à trouver

L'intégration avec notre outil CRM maison "SugarForce", codé en Delphi par Mr Paul, ancien interne polyvalent décédé depuis

Un dacheborde, parcequ'il parait que cela booste la productivité des forces de vente

Avec bien entendu des widgets 2.0 pour dynamiser l'ensemble

Non seulement c'est peu précis, vague, mal défini, mais quand vous lisez la dernière ligne, généralement l'envie vous prend d'arrêter ce métier séance tenante pour partir élever des chèvres dans le Larzac :

Pouvez-vous me fournir un devis à tiroirs et vous engager sur une livraison à la rentrée prochaine ?

PS : Je serai absent du 1er juillet au 31 août, voyez avec ma secrétaire (en congés du 15/07 au 15/08) pour toute questions complémentaires PPS : Je vous ai parlé de l'application Blackberry ?

Peut-on imaginer comparer ce type de demande à l'achat d'une voiture en concession ?

Allez, j'ai dix minutes à tuer, je vous imagine la discussion :

fish, par ferdinandreus

— Bonjour monsieur le concessionnaire
— Bonjour monsieur le client
— Je voudrais acheter une voiture
— Ma foi, vous êtes au bon endroit ! Quel modèle vous a tapé dans l'oeil ?
— Je veux quelque chose d'assez standard, comme celle-ci là bas, mais avec quelques ajustements mineurs ; j'aime bien l'arrière de celle-ci, l'avant de celle-là, l'aspect cabriolet de la petite là-bas, et le bas de caisse de celle cachée dans le fond, là. Il faudra aussi qu'elle soit amphibie, je compte aller pêcher avec quelques amis le week-end prochain. Idéalement, elle pourra également passer d'un mode cabriolet à mobile-home d'une simple pression sur un bouton en cas d'embouteillages prolongés. Avec le meilleur moteur que vous ayez à disposition, cela va sans dire. Ah, précisons tout de suite : il me la faut pour le week-end prochain, puisque j'ai une partie de pêche, vous vous souvenez ? Bien entendu, je me résèrve le droit de vous demander dans ce laps de temps quelques options supplémentaires auxquelles je n'ai pas pensé. Vous avez le tarif catalogue sous la main ?
— PAN ! (bruit de déflagration)

Redevenons sérieux deux secondes. Le développement d'une application Web sera toujours spécifique et sur-mesures, arrêtons de nourrir l'illusion qu'en utilisant des outils Open Source relativement standardisés techniquement, nous standardisons fonctionnellement les développements. Ce n'est tout simplement pas vrai 99% du temps.

Et pour les fans de maquillage d'outils tout-prêts et autres produits industrial-wanabee, j'utilise souvent la formule suivante auprès de mes clients :

Un développement spécifique adaptera l'outil à votre métier ; un CMS adaptera votre métier à l'outil. La balle est dans votre camp (ou accessoirement dans votre pied.)

Ce qui m'amène à un deuxième constat que je fais de plus en plus au gré des avant-ventes ; il existe bel et bien deux métiers distincts, que beaucoup de prospects (et hélas, soyons francs, de prestataires) confondent allégrement :

le métier d'intégrateur de solutions ;
le métier de concepteur de solutions spécifiques.

J'identifie la part de demandes entrantes du premier type de prestation à environ 80%, si ce n'est plus. J'ai personnellement décidé en créant mon activité de me consacrer exclusivement aux 20% restants. Et ma vie a changé, en plus mieux. Juste pour dire.

« Parle pas aux cons, ça les instruit »

La moindre tentative de développement modulaire et par priorité sera rejetée et incomprise.

Les méthodes agiles seront rejetées par la grande majorité des clients par peur. J’en viens même à penser que c’est une perte de temps d’en parler.

Oui, n'en parlons plus et subissons sans broncher, c'est plus confortable intellectuellement. Et puis si ça se vend plus facilement comme ça, pourquoi diable hésiter ? Faut juste s'habituer à marcher en canard au troisième recommandé avec AR. Ah mais oui je suis con, le commercial ayant vendu la chose a déjà touché sa comm' et ne gère plus les conséquences de sa vente depuis longtemps, j'oubliais.

The Fear, par stumayhew

Sérieusement, il faut se battre. Il faut chercher à convaincre, expliquer sans relâche. Et en cas de blocage rhédibitoire, ne rien lâcher, car d'expérience quelqu'un qui n'accepte aucune concession sur un plan méthodologique ne vous passera vraisemblablement rien sur les aspects commerciaux.

De plus dans les méthodes de développement modulaires et surtout évolutives, les litiges sont beaucoup plus complexes à gérer.

Si litige il y a, c'est vraisemblablement que les principes fondamentaux de l'agilité n'ont jamais été appliqués sur le projet en question. Quelques rappels issus du manifeste agile :

Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan

Vous avez noté le point 3 ? Ah ben zut. Et je vous parle pas des trois autres, j'imagine que la lecture du compte-rendu de la décision de justice post-echec-projet vous accapare déjà un temps précieux.

Enfin, j'aimerai bien savoir qu'est ce qui rend les litiges plus évidents à gérer à grands coups d'avenants avec A/R sur un forfait plutôt qu'un bon vieux dialogue autour d'une table dans le cadre d'un projet agile ?

Gérer des litiges contractuels est un véritable métier, très pointu, qui demande de grosses compétences et un sang-froid certain. Ce métier ne me passionne personnellement pas, et je ne peux me résoudre à le considérer comme une fatalité inhérente à mon corps de métier. Je suis là pour fournir des réponses à des besoins précis, quitte à fournir une assistance pour faciliter leur formulation, dans la collaboration et le respect mutuel, au travers d'une communication de type horizontal. J'axe toute relation avant tout sur la confiance. Libre à chacun de se raconter que tout ceci n'est qu'utopie, mais force est de constater qu'après un an d'activité je trouve des gens (des clients pardon, je crois que je m'y ferai jamais) qui embrassent cette manière de fonctionner. Avec d'excellents résultats, par ailleurs.

Par contre, il est clair qu'avec de telles exigences, je ne donne pas suite à neuf appels entrants sur dix. Le mot est lâché : je refuse des opportunités business. SACRILÈGE ! Combien de gens me regardent avec des yeux ronds lorsque je raconte ça… C'est déprimant, d'un certain côté. Travailler plus pour gagner plus ? Et si on parlait plutôt de travailler mieux pour vivre mieux ?

Courir plus pour s'essouffler plus

(…) si ça implique une absence de visibilité sur une enveloppe globale sur laquelle on s’engage, (c')est tout simplement rédhibitoire pour le client

La visibilité s'obtient par la connaissance de la capacité à produire en collaboration avec le client (on appelle ça la vélocité, dans le jargon agile). C'est complètement utopique de prétendre estimer une capacité à produire sans connaître la capacité du client à fournir les éléments nécessaires à l'obtention de cette productivité dans la collaboration. Et par pitié, qu'on ne me parle pas du cahier des charges de 400 pages que personne ne lit puisqu'obsolète au bout d'une semaine, le besoin ayant déjà changé par trois fois suite à la remontée de l'avis du numéro deux groupe/worldwide et de sa cousine Berthe qui est en deuxième année aux Gobelins.

Enfin, je réalise que beaucoup de gens comprennent l'agilité comme la capacité à faire du business malgré tout, voire à tomber du projet coûte que coûte, en s'adaptant aux obstacles au gré du vent et avec les moyens du bord (qui prennent souvent la forme de stagiaires chef de projet et autres experts techniques junior recrutés à la râche pour faire face à un surcroît de charge non prévue, soit dit en passant). C'est juste tout l'inverse ; je ne connais rien de plus structurant et contraignant en termes de processus que les méthodes agiles ! Il n'y a pas de vaudou, l'obtention de résultats est à ce prix. Ainsi que d'une certaine façon, au prix d'un lâcher-prise et d'une certaine acceptation du changement, de chaque côté de la barrière (si tant est qu'il y en ait une).

High Wire Act, par beginasyouare

« Bon, tu conclues là ? J'vais rater l'apéro »

Oui, je suis un peu décontenancé à la lecture de ces quelques commentaires. On constate tous que bien des commanditaires ne comprennent pas les enjeux de leur métier d'acheteur de prestation de développements informatiques. Je découvre qu'il est des professionnels tellement désabusés qu'ils ont visiblement renoncé à toute vélléité d'éducation de leurs prospects sur les questions d'organisation méthodologique et collaborative du travail, part intégrante du champ d'expertise de tout prestataire de développement informatique un tant soit peu digne de ce nom et prétendant offrir un conseil de qualité. Je ne peux me résoudre à croire qu'ils n'ont pas le choix, que tout ceci est inévitable, et que « c'est la crise, il faut bien bouffer, ma pauvre dame ».

Je pense au contraire qu'une part importante de notre métier, j'irai même jusqu'à parler de notre devoir déontologique, est de les accompagner dans la compréhension de leur rôle dans les processus collaboratifs projet afin de maximiser le potentiel de réussite de ces derniers coûte que coûte. Et d'apprendre à dire non lorsque cela s'avère nécessaire, plutôt que de s'engluer dans cette vision fataliste, nivelant par le bas la qualité globale d'une partie grandissante des réalisations auquel le Web est confronté (france.fr anyone?).

Vous pouvez maintenant basher en commentaire, c'est fait pour ça ;)

Hosting a Symfony app on NginX using PHP-FPM

2010-09-27T00:00:00+02:00

I recently had to make a capacity planning study for a client of mine for which I've been developing a Symfony application. Despite the hardware/cloud architecture problem, I also tried to optimize application performances from a webserver software point of view (the application is currently hosted on a standard Apache2 server using mod_php5). I dug Google a bit and found some very enthusiastic comments on PHP-FPM, a PHP FastCGI implementation and the NginX web server.

While PHP-FPM has just made it to PHP core in version 5.3.3, the OS version of the linux server we are using, Ubuntu 10.04 LTS, only ships with 5.3.2. Fortunately, Brian Mercer released a PHP-FPM sapi for these particular OS and PHP versions.

So installing PHP and PHP-FPM on Ubuntu Lucid Lynx is as easy as:

$ sudo apt-get install install python-software-properties
$ sudo add-apt-repository ppa:brianmercer/php
$ sudo apt-get update
$ sudo apt-get install php5-cli php5-common php5-mysql php5-suhosin \
    php5-gd php5-fpm php5-cgi php-pear php5-memcache php-apc

Of course, feel free to add any supplementary packages you need. To start up the PHP-FPM service, run:

$ sudo service php5-fpm start

As a side note, the service will run on port 9000 by default, but you can tweak this up by editing its configuration file located at /etc/php5/fpm/php-fpm.conf.

Now, let's install the NginX web server:

$ sudo apt-get install nginx

That's it. Let's create a new site configuration for our Symfony application in a new /etc/nginx/sites-available/mywonderfulwebsite.org file:

server {
    set $website_host "mywonderfulwebsite.org";
    set $website_root "/var/www/mywonderfulwebsite/web";
    set $default_controller "index.php";
    set $symfony_root "/var/www/mywonderfulwebsite/lib/vendor/symfony";

    listen 80;
    server_name $website_host;

    # Gzip
    gzip on;
    gzip_min_length 1000;
    gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
    gzip_disable "MSIE [1-6]\.";

    access_log /var/log/nginx/$website_host.access.log;

    root $website_root;

    index $default_controller;

    charset utf-8;

    location /sf {
        # path to folder where all symfony assets are located
        alias $symfony_root/data/web/sf;
        expires max;
    }

    location / {
        # If the file exists as a static file serve it directly without
        # running all the other rewite tests on it
        if (-f $request_filename) {
            expires max;
            break;
        }

        if ($request_filename !~ "\.(js|htc|ico|gif|jpg|png|css)$") {
            rewrite ^(.*) /$default_controller$1 last;
        }
    }

    location ~ "^(.+\.php)($|/)" {

        set $script $uri;
        set $path_info "/";

        if ($uri ~ "^(.+\.php)($|/)") {
            set $script $1;
        }

        if ($uri ~ "^(.+\.php)(/.+)") {
            set $script $1;
            set $path_info $2;
        }

        include /etc/nginx/fastcgi_params;
        fastcgi_pass 127.0.0.1:9000;

        fastcgi_param SCRIPT_FILENAME $website_root$script;
        fastcgi_param SCRIPT_NAME $script;
        fastcgi_param PATH_INFO $path_info;
    }
}

As you may have noticed, I'm taking part of the convenient custom variable system of the NginX configuration syntax, so you'll probably just have to adapt the $website_host, $website_root, $default_controller and $symfony_root variables to your project needs.

Enabling the website is achieved with a symbolic link, like this:

$ sudo ln -sf /etc/nginx/sites-available/mywonderfulwebsite.org \
              /etc/nginx/sites-enabled/mywonderfulwebsite.org

Last but not least, don't forget to launch the webserver:

$ sudo /etc/init.d/nginx start

I did some benchmarks but unfortunately the hardware configuration being quite different between the old and the new platform, the statistics generated did not make much sense. But the reactivity of the application, and memory footprint is much much better with the new setup (I know, this is not a very scientific statement).

Sources

A First Look at node.js and Express

2010-09-01T00:00:00+02:00

With all the hype coming to server-side Javascript lately, especially around Node, I was feeling the need to give it a try to see how it goes. Also, getting back to work after three full weeks of unwired holidays was hard enough to worth deserving some playtime with cool and fun technologies.

Node is described as an Evented I/O Framework for Google's V8 JavaScript Engine. Think of it as a toolkit to produce high-performance distributed, event-driven and scalable non-blocking network servers. Okay, whatever the way I want to describe the project, it's buzzword-bingo™. Let's say it's mainly about catching events and react accordingly, to make load distribution and parallel processing easier and more effective.

Installing Node

Installation on my Mac went smoothly and took nearly two minutes by compiling it from the sources; here's how I did (there might be easier or better ways, I don't really care):

$ mkdir tmp
$ git clone http://github.com/ry/node.git
$ cd node
$ ./configure && make && sudo make install

You now have access to the node executable available on your system.

A simple example of a Node HTTP server (put the code below in a test.js file):

var http = require('http');

var server = http.createServer(function(req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.write('Hello World');
  res.end();
});

server.listen(3000, "127.0.0.1");

Then launch the created webserver using the command line:

$ node test.js

And point your browser at http://127.0.0.1:3000 to get printed Hello World. Neat, huh?

Introducing Express, a Web Framework on top of Node

Express is a Web framework built on top of Node, HTTP and Connect, allowing easy creation of full-fledged Web applications. It has routing, handles environments as well as several template engines and much more.

Installation is as easy as Node's one, so here we go:

$ git clone http://github.com/visionmedia/express.git
$ cd express
$ git submodule update --init
$ sudo make install && sudo make install-support

That's it. You can now write your own test application, eg. in a new hello.js file:

var app = require('express').createServer();

app.get('/', function(req, res){
    res.send('Hello World');
});

app.get('/hello/:name', function(req, res){
    res.send('Hello ' + req.param('name') + '!');
});

app.listen(3000, "127.0.0.1");

console.log('Server running at http://127.0.0.1:3000/');

Launch your webapp server by the command line:

$ node hello.js

Express and will create a Node server listening to the local port 3000, so head your favorite browser to http://127.0.0.1:3000/ then http://127.0.0.1:3000/hello/niko to get the picture of what the above code does. Those familiar with Web framework such as rails, django or symfony won't be much disturbed.

Express also ships with an express executable which provides useful commands. To create a new hello application skeleton, just run:

 $ express hello
   create : hello
   create : hello/app.js
   create : hello/logs
   create : hello/public/javascripts
   create : hello/pids
   create : hello/public/stylesheets
   create : hello/public/stylesheets/style.less
   create : hello/public/images
   create : hello/views/partials
   create : hello/views/layout.jade
   create : hello/views/index.jade
   create : hello/test
   create : hello/test/app.test.js

Above command just created an hello project directory where you can cd into and launch the server by its default front controller app.js:

$ cd hello
$ node app.js
Express server listening on port 3000

Note that the generated project skeleton implies using Jade as a tremplate engine and the Less CSS syntax, while one might want to use something else, which is perfectly possible by configuring the project differently.

Next steps documentation will be provided by official Express documentation.

Of course, Express might not be as full-featured as older well-established Web frameworks, but for simple needs it can be pretty easy to setup and deploy, and — probably equally importantly — fun to play with and learn.

Conclusion

As you can see, installing and using Node and Express is quite straightforward, even if you have to dig into the deeper Web to find docs, when they exist. Javascript is a great, agile and well-known language, and taking part of it server-side definitely makes sense if you want my opinion.

Let's see how this will evolve in the future, as there are not as many backend-oriented libs in JavaScript as there are in other languages like python, ruby or php yet. But more and more node modules are appearing day after day, such as Mongoose or Socket.IO, which I'll definitely be playing with as soon as possible.

Thanks for your attention, have fun, take care and don't break the Web.

Tâches de déploiement spécifiques avec Symfony

2010-05-25T00:00:00+02:00

Symfony propose une tâche de déploiement distant utilisant rsync fort pratique : une fois configurés les paramètres du serveur distant dans le fichier config/properties.ini de votre projet, un simple appel en ligne de commande synchronisera les fichiers du projet présents sur votre système de fichiers local vers l'hôte distant. Et si vous utilisez une clé SSH, l'opération ne vous demandera même pas de saisir votre mot de passe !

$ ./symfony project:deploy monserveur --go

Mais bien souvent, nous avons besoin de plus : préparer un certain nombre de fichiers statiques comme les assets CSS, JavaScript ou les images, ou vider le cache sur la ou les machines distantes pour prendre en compte d'éventuelles modifications de la configuration ou du templating sur la plateforme de production (qui exploite l'environnement du même nom, nous sommes bien d'accord).

Aussi, il est très simple de faire face à ces besoins spécifiques en créant vous même une tâche de déploiement projet, en surclassant la classe sfProjectDeployTask fournie en standard par Symfony. Par exemple, voici la tâche de déploiement que j'utilise pour la mise à jour du site Akei, exploitant mon plugin npAssetsOptimizerPlugin pour la gestion de la minification et l'assemblage des fichiers JavaScript, CSS et images PNG :

<?php
class AkeiDeployTask extends sfProjectDeployTask
{
  /**
   * @see sfProjectDeployTask
   */
  protected function configure()
  {
    $this->addArguments(array(
      new sfCommandArgument('server', sfCommandArgument::REQUIRED, 'The server name'),
    ));

    $this->addOptions(array(
      new sfCommandOption('go', null, sfCommandOption::PARAMETER_NONE, 'Do the deployment'),
      new sfCommandOption('rsync-dir', null, sfCommandOption::PARAMETER_REQUIRED, 'The directory where to look for rsync*.txt files', 'config'),
      new sfCommandOption('rsync-options', null, sfCommandOption::PARAMETER_OPTIONAL, 'To options to pass to the rsync executable', '-azC --force --delete --progress'),
      new sfCommandOption('optimize', null, sfCommandOption::PARAMETER_OPTIONAL, 'The asset optimizations to make before deploying'),
    ));

    $this->namespace = 'akei';
    $this->name = 'deploy';
    $this->briefDescription = 'Deploys Akei website to a given server';
  }

  /**
   * @see sfProjectDeployTask
   */
  protected function execute($arguments = array(), $options = array())
  {
    // Assets
    if (!is_null($options['optimize']))
    {
      $this->logSection('deploy', 'assets optimization before deploying');
      $task = new npOptimizeAssetsTask($this->dispatcher, $this->formatter);
      $task->run(array('application' => 'main'), array('type' => $options['optimize']));
    }

    // Deployment
    $this->logSection('deploy', 'deploying...');
    parent::execute($arguments, $options);

    // Remote symfony cc
    if ($options['go'])
    {
      $this->logSection('deploy', 'remote cache clear');
      $this->getFilesystem()->execute('ssh user@monserveur.foo "/path/to/www/akei/symfony cache:clear"');
    }

    $this->logSection('deploy', 'done.');
  }
}

Comme vous pouvez le constater, cette tâche déclare un espace de nom akei et propose une option supplémentaire, optimize, permettant de préparer les assets avant déploiement :

$ ./symfony akei:deploy monserveur --optimize=stylesheet --go

Cette commande va tout simplement minifier et assembler les feuilles de style définies par la configuration du plugin npAssetsOptimizerPlugin, déployer les fichiers en production sur la machine monserveur et vider le cache sur la machine distante une fois l'opération effectuée.

Notez d'ailleurs l'emploi du très pratique appel à $this->getFilesystem()->execute(), qui permet d'executer des appels à la ligne de commande locale depuis la classe de tâche elle-même ; ici, une execution distante à travers SSH.

Bien entendu, cet exemple est très spécifique aux besoins du site Akei, mais vous pourriez en quelques minutes gérer plus finement une tâche de déploiement plus générique et configurable. Pensez-y pour vos projets ;)

PS : Ce billet a été écrit en 14 minutes. Merci de votre compréhension.

Formation Symfony Doctrine

2010-05-23T00:00:00+02:00

Une nouvelle offre de formation Symfony 1.4 et Doctrine 1.2 sur 4 jours a été publiée sur le site aujourd'hui :

Cette formation sur quatre journées consécutives, a pour but de donner toute autonomie aux développeurs PHP5 aguéris à la pratique de la Programmation Orientée Objet pour développer des applications Web en utilisant le framework Symfony 1.4 et l'ORM Doctrine 1.2.

Comme d'habitude, n'hésitez pas à prendre contact si vos besoins sont éventuellement plus spécifiques, il est toujours possible de concevoir une formation sur mesure totalement adaptée.

Installer Django dans un environnement Python virtuel avec pip, virtualenv et virtualenvwrapper

2010-05-05T00:00:00+02:00

Ce billet résume les étapes nécessaires pour installer un ou plusieurs environnements de développement Django fonctionnels, portables et faciles à maintenir sous Mac OS X.

Même si Django est un framework relativement simple à installer, lorsqu'il s'agit de développer plusieurs projets mettant en œuvre différentes versions de ce dernier ou de librairies tierces nécessaires pour assurer son bon fonctionnement, le casse-tête peut rapidement devenir ingérable si l'on ne prend pas garde à bien isoler le contexte applicatif dans un environnement dédié, isolé du reste du système.

Concrètement, imaginons que j'ai deux projets Django :

Le projet A utilise Django 1.2-DEV, django_toolbar en version 0.8.3 et Python 2.6
Le projet B utilise Django 1.1 et Pinax en version 0.6 tournant avec Python 2.5

Impossible dans ces conditions d'utiliser une version unique de chacune des librairies installées sur le système (et non, l'utilisation de liens symboliques et de préfixes n'est pas une solution acceptable sur le moyen/long terme).

Aussi, découvrant progressivement la richesse de l'écosystème Python, je n'ai pas manqué de m'extasier devant la puissance et la simplicité d'outils tels que pip, virtualenv et virtualenvwrapper pour répondre à ces questions.

`pip`, un installeur de paquet simple et efficace

D'aucuns de ceux qui utilisent une distribution Linux connaissent le bonheur d'utiliser un gestionnaire de paquets. L'installation de programmes et de librairies s'effectuent la plupart du temps en ligne de commande, et la résolution des dépendances est totalement prise en charge de façon transparente.

pip est un gestionnaire de paquets Python, écrit lui-même en Python, qui tient ce rôle à merveille. L'installation de pip est fort simple, pour peu de disposer de setup_tools :

$ sudo easy_install pip

Pour installer un paquet, par exemple la dernière version stable de Django (la 1.1.1), il vous suffit de taper en ligne de commande :

$ sudo pip install Django

Pour chercher un paquet, c'est aussi simple que :

$ pip search django-debug-toolbar

`virtualenv`, un environnement Python virtuel étanche et cloisonné

virtualenv vous propose ni plus ni moins de créer à la demande des environnements de travail virtuels pour tout ce qui touche à Python : chaque environnement possède ses propres paquets et librairies, voire dispose de sa propre version de l'interpréteur !

virtualenvwrapper, quand à lui, est un jeu de scripts utilitaires permettant de créer, modifier, supprimer et - d'une façon plus générale - de travailler efficacement avec virtualenv.

L'installation de virtualenv et de virtualenvwrapper, ça tombe bien, peuvent se faire directement via pip :

$ sudo pip install virtualenv virtualenvwrapper

Pour finir de configurer l'installation de virtualenv, il nous reste cependant quelques étapes supplémentaires.

Tout d'abord, il nous faut créer le répertoire qui contiendra nos environnements virtuels sur notre machine ¹ :

$ mkdir ~/.virtualenvs

Il faut également renseigner ce chemin dans la variable d'environnement $WORKON_HOME et instancier la gestion des environnements virtuels, le plus simple étant alors de placer les déclarations ad-hoc dans le fichier ~/.profile de votre compte utilisateur ² :

$ echo "export WORKON_HOME=$HOME/.virtualenvs" >> ~/.profile
$ echo "export PIP_VIRTUALENV_BASE=$WORKON_HOME" >> ~/.profile
$ echo "export PIP_RESPECT_VIRTUALENV=true" >> ~/.profile
$ echo "source /usr/local/bin/virtualenvwrapper.sh" >> ~/.profile

Note : il se peut que selon le mode d'installation utilisé, le chemin vers le fichier /usr/local/bin/virtualenvwrapper.sh soit à adapter spécifiquement.

Comme nous venons d'ajouter des directives à notre fichier ~/.profile, il faut le recharger :

$ source ~/.profile

Créer son premier environnement virtuel

Reprenons le cas de nos deux projets A et B ; nous avons besoin de créer deux environnements virtuels distincts pour travailler sereinement avec les paquets adéquats pour chacun d'eux :

Nous allons nous concentrer sur la création du premier environnement, pour l'occasion destiné à travailler sur le projet A :

$ mkvirtualenv DjangoEnvX --no-site-packages
New python executable in DjangoEnvX/bin/python
Installing setuptools............done.

L'environnement a été créé. Notez trois choses importantes :

Les setuptools ont été installés dans l'environnement, ainsi que pip même s'il n'en est pas fait mention ; cela nous permettra de disposer de moyens d'installation depuis l'environnement en question ;
L'option --no-site-packages a été passée, ce qui permet de constituer un environnement intégralement vierge de tout paquet Python. Ne pas passer l'option aurait lié l'ensemble des paquets installés sur le système dans notre environnement de développement, ce que nous ne voulons justement pas !
Je ne nomme pas l'environnement de travail du nom du « Projet A », dans la mesure où cet environnement pourrait éventuellement être réutilisé pour d'autres projets ayant des besoins et contraintes similaires.

Mais examinons de plus près ce que la commande mkvirtualenv a créé pour nous :

~$ workon DjangoEnvX
(DjangoEnvX)~ $ cdvirtualenv
(DjangoEnvX)~/.virtualenvs/DjangoEnvX $ ls -l
total 8
drwxr-xr-x   6 niko  staff  204 May  5 16:08 .
drwxr-xr-x  14 niko  staff  476 May  5 16:08 ..
lrwxr-xr-x   1 niko  staff   63 May  5 16:08 .Python -> /System/Library/Frameworks/Python.framework/Versions/2.6/Python
drwxr-xr-x   9 niko  staff  306 May  5 16:08 bin
drwxr-xr-x   3 niko  staff  102 May  5 16:08 include
drwxr-xr-x   3 niko  staff  102 May  5 16:08 lib

Notez les éléments suivants :

L'utilisation de la commande workon, fournie par virtualenvwrapper, qui permet d'activer un environnement virtuel de travail ; l'autocomplétion du nom de l'environnement virtuel est d'ailleurs disponible !
La commande cdvirtualenv nous place directement à la racine du répertoire de l'environnement virtuel ;
Les répertoires bin, include et lib ont été créés, ainsi qu'un lien symbolique vers la version de l'intérpréteur Python du système.
Un préfixe (ici (DjangoEnvX)) est ajouté devant le prompt lorqu'on travaille dans un environnement spécifique : cela permet de toujours savoir dans quel environnement on travaille, afin d'éviter les mauvaises surprises ;)

Je peux maintenant installer sereinement les paquets dont j'ai besoin dans le cadre de mon projet A, où que je sois sur le système de fichiers. Par exemple, pour installer la version de dev de Django 1.2 depuis son mirroir git :

(DjangoEnvX)~ $ cd ~
(DjangoEnvX)~ $ pip install -e git+http://github.com/django/django.git#egg=django

Vérifions que la version de développement de Django a bien été installée dans notre environnement DjangoEnvX :

(DjangoEnvX)~ $ cdvirtualenv
(DjangoEnvX)~/.virtualenvs/DjangoEnvX $ ll src
total 0
drwxr-xr-x   3 niko  staff  102 May  5 17:07 .
drwxr-xr-x   7 niko  staff  238 May  5 17:08 ..
drwxr-xr-x  16 niko  staff  544 May  5 17:08 django
(DjangoEnvX)~/.virtualenvs/DjangoEnvX $ echo -e "import django\nprint django.get_version()"|python
1.2 beta 1

Installons maintenant de la même façon le paquet django-debug-toolbar en version 0.8.3 :

(DjangoEnvX)~ $ pip install -e git+git://github.com/robhudson/django-debug-toolbar@0.8.3#egg=django-debug-toolbar

Nous avons maintenant nos paquets installés, créons un nouveau projet Django. On peut créer un répertoire n'importe où sur le système de fichiers, cela n'a aucune importance : les environnements virtuels et les projets ne sont pas directement liés.

(DjangoEnvX)~ $ cd ~/Sites/
(DjangoEnvX)~/Sites $ django-admin.py startproject my_django_project
(DjangoEnvX)~/Sites $ cd my_django_project/
(DjangoEnvX)~/Sites/my_django_project $ ll
total 24
drwxr-xr-x   6 niko  staff   204 May  5 17:36 .
drwxr-xr-x  94 niko  staff  3196 May  5 17:36 ..
-rw-r--r--   1 niko  staff     0 May  5 17:36 __init__.py
-rwxr-xr-x   1 niko  staff   546 May  5 17:36 manage.py
-rw-r--r--   1 niko  staff  3313 May  5 17:36 settings.py
-rw-r--r--   1 niko  staff   564 May  5 17:36 urls.py
(DjangoEnvX)~/Sites/my_django_project $ ./manage.py runserver
Validating models...
0 errors found

Django version 1.2 beta 1, using settings 'my_django_project.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Voila, nous pouvons travailler sur notre projet dans l'environnement DjangoEnvX l'esprit serein. On pourra éventuellement ajouter d'autre paquets, ceux-ci ne seront toujours installés que pour cet environnement. Si d'aventure nous voulions versionner la liste des dépendances installées va pip, c'est aussi simple que :

(DjangoEnvX)~/Sites/my_django_project $ pip freeze > requirements.txt

Le fichier requirements.txt ainsi créé contiendra la liste de tous les paquets installés dans l'environnement DjangoEnvX :

(DjangoEnvX)~/Sites/my_django_project $ cat requirements.txt
-e git+http://github.com/django/django.git@25a45619fe5d7ff3d4f2dbf8f8879a3a00c3625d#egg=Django-1.2_beta_1-py2.6-dev
-e git://github.com/robhudson/django-debug-toolbar@ee1811238e91ae0ad33413b0d40d2f8482101951#egg=django_debug_toolbar-0.8.3-py2.6-dev
wsgiref==0.1.2

Libre à vous alors de versionner ce fichier, ce qui permettra à vos collaborateurs d'instancier un nouvel envronnement de travail et d'installer les dépendances requises d'une simple ligne de commande sur son poste de travail :

(WtfDevEnv)$ pip install -r /path/to/requirements.txt

En espérant vous avoir été utile avec ce billet, je m'en retourne vaquer à mes occupations, et vous rappelle à toutes fins utiles qu'Akei serait quand même super contente d'avoir un coup de fil de votre part pour travailler sur vos chouettes projets en devenir, pourquoi pas en créant plein de virtualenv Python sympas comme tout ;)

Edit : Prise en compte de la variable d'environnement PIP_RESPECT_VIRTUALENV pour que pip detecte automatiquement la présence d'un environnement virtuel lors de son utilisation (merci Mathieu !)

Vous pouvez bien entendu créer ce répertoire où bon vous semble sur votre système, à partir du moment où votre utilisateur a les droits de lecture et d'écriture dessus. ↩
le fichier ~/.profile est chargé à chaque démarrage de session Max OS X. Utilisateurs de GNU/Linux, l'équivalent est le fichier ~/.bashrc. ↩