L’article est également disponible en PDF si vous souhaitez.

L’article !

Un injecteur de dépendances ? Peut être cela ne vous parle il pas vraiment. Tant mieux, l’objectif de cet article est d’éclaircir ces termes, et de présenter une implémentation que j’ai eu l’occasion de mettre en place, en essayant de m’appuyer sur de bonnes pratiques logicielles.

Cet article est basé sur mon expérience personnelle, ainsi que sur des recherches effectuées lors de la réalisation d’un composant logiciel. L’objectif n’est aucunement d’imposer ma vision des choses, mais bel et bien de partager les interrogations, réflexion et découvertes que nous avons eu alors.

Nous parlerons ici de l’injecteur de dépendances de Spiral, un framework maison réalisé avec quelques amis, et dont l’objectif principal est de découvrir les rouages des frameworks, ainsi que de nous initier aux bonnes pratiques logicielles.

Alors que nous travaillions sur ce projet, notre principal but était de réellement comprendre, dans le détail, comment un injecteur de dépendances pouvait fonctionner. Ré-inventer la roue, pour mieux comprendre comment une roue fonctionne, en quelque sorte.

Aussi, l’objectif de ce document n’est pas de fournir une documentation sur l’utilisation du composant, mais bien d’expliquer comment nous l’avons réalisé.

L’injecteur de dépendances est disponible dans une version intégrée à Spiral ou dans une version standalone. Vous pouvez trouver le code sur le dépôt mercurial du projet.

A l’heure ou j’écris ces lignes, l’injecteur de dépendances de spiral n’est pas encore terminé (sept 09), mais est dans un état avancé, et devrait être disponible en novembre 2009.

L’ensemble des exemples de ce document sont en PHP, mais les concepts discutés ici peuvent être (et sont!) implémentés dans d’autres langages.

Donc, parlons un peu d’injection de dépendances !

Comment gérons-nous nos objets ?

Avant toute chose, il est indispensable de bien comprendre ce qu’est l’inversion de contrôle.

Lorsque nous réalisons des logiciels en utilisant le paradigme orienté objet, nous travaillons avec des classes, et la majeure partie du temps, nous faisons interagir ces classes entre elles. En pratique, certaines classes sont dépendantes d’autres classes.

Pour mettre un exemple derrière ces concepts, tout au long de ce document, nous allons nous mettre dans la peau d’Alice, une jeune fille qui adore manger des glaces, spécialement celles à la fraise !

Certains disent même qu’Alice est dépendante de la glace à la fraise.

Il est clair, au regard de cette implémentation, qu’à chaque fois qu’Alice mange une glace, il s’agit d’une glace à la fraise. Génial, mais un jour, la mère d’Alice souhaite lui faire découvrir d’autres parfums…

En réalité, avec cette implémentation, il est impossible de changer la glace qu’Alice va manger.

Inversion de Contrôle (IoC)

Principe

Il apparait donc nécessaire de supprimer les dépendances entre nos deux classes, pour permettre à Alice de gouter de nouveaux parfums.

Comment ? C’est assez simple, regardez donc le code:

Quand Alice mange une glace (via la méthodemangerGlace), nous devons lui passer la glace, ce n’est plus elle qui choisit, nous le faisons à sa place.

Ce principe est connu comme étant le principe d’Hollywood: « Ne nous appelez pas, nous vous appellerons» . En d’autres termes, n’utilisez pas l’opérateurnewdans vos classes, mais préférez passer (ou qu’on vous passe) les objets par référence.

Alice peut faire d’autres choses avec sa glace, la laisser tomber par terre par exemple (oups!), grâce à la méthodelacherGlace(). Nous pouvons alors choisir de passer la glace à cette méthode également, ou choisir de la donner directement à Alice, la laissant s’occuper du reste, et évitant de lui passer une glace pour chaque action qui en nécessite une.

Il est bien plus facile maintenant de choisir la glace à donner a Alice, et ainsi de contrôler les dépendances d’Alice vis à vis de la glace.

Ici, il subsiste des dépendances dans le code. Il s’agit de dépendances vis à vis de contrats (interfaces) et non d’implémentations données (classes), puisque j’ai choisi d’utiliser le paradigme de programmation par contrats.

Et c’est tout pour le principe d’inversion de contrôle (pas les glaces à la fraise, contrôler les dépendances)! Il s’agit simplement du fait d’inverser le flux de contrôle de vos application, en déléguant à un plus haut niveau la création des objets.

Injection de dépendances

Maintenant que le concept d’inversion de contrôle est clair, expliquons ce qu’est l’injection de dépendances. Les deux concepts sont assez proches, et souvent utilisés de pair, mais il est important de bien saisir la frontière entre les deux.

Dans la méthodemangerGlace, nous considérons que la glace en question est déjà donnée à Alice. C’est un comportement vraiment utile: Nous n’avons plus à nous occuper de la manière dont la glace est arrivée là, nous l’avons déjà (dans une propriété privée par exemple).

Dans la section précédente, Alice était dépendante de sa glace. En inversant le flux de contrôle, le comportement d’Alice vis à vis des glaces est plus facilement contrôlable, et testable (utiliser des mocks, ou bouchons de tests est aussi facile que de régler une propriété, nous parlerons de tests plus tard).

Notre travail (celui de la mère d’Alice), est de créer les objets et de les passer à Alice. Les injecter est le bon mot. En utilisant des mutateurs, ou en utilisant le constructeur, injectant les objets nécessaires.

Allons-y:

L’inversion de contrôle est donc le fait d’exposer des méthodes publiques (ou des constructeurs) pour régler certaines propriétés, et l’injection de dépendances est le fait de, justement, injecter ces dépendances, utiliser ces méthodes et constructeurs.

Un Conteneur ?

L’exemple utilisé jusqu’ici est volontairement simple, et il à été choisi afin d’expliquer les concepts le plus clairement possible: Nous avons uniquement deux classes, et une dépendance.

En pratique, vous serez surement d’accord pour dire qu’un projet est rarement aussi simple. Aussi, dans les projets importants, la gestion du cycle de vie des objets et de l’injection de leurs propriété peut rapidement devenir un vrai casse tête.

L’idéal est alors d’automatiser le processus de création, d’injection et de gestion de ces cycles de vie. Le conteneur fait exactement ça.

Pourquoi « conteneur»  ? Parce que la création automatique et l’injection est effectuée grâce à un objet, qui se charge de contenir toutes les informations sur les dépendances. Une fois les objets crées, le conteneur garde une référence vers ces derniers au cas ou nous en aurions encore besoin (voir la définition de portée d’un service – les « scopes» - plus loin)

Le conteneur va donc se charger d’injecter les objets pour nous, en quelque sorte, il fait le travail de la Mère d’Alice à sa place.

Nous souhaitons donc que lorsque nous appellerons Alice, via le conteneur, elle nous soit retourné avec une glace prête à être mangée !

Ici, le conteneur à injecté la bonne glace à Alice (peu importe laquelle d’ailleurs, nous souhaitons juste avoir une glace)

Si la glace elle même avait été dépendante d’autres objets (disons, des noix de coco par exemple), c’est le rôle du conteneur que de résoudre l’ensemble des dépendances, dans le bon ordre, simplifiant au maximum la tâche de gestion des dépendances entre les objets et les classes, laissant la tâche simple pour le développeur.

Concepts logiciels

Maintenant que les concepts d’inversion de contrôle et d’injection de dépendances sont clairs (enfin, j’espère!), nous pouvons commencer à parler de comment nous avons réalisé cette bibliothèque.

Les concepts discutés ici sont des concepts assez simples, dont le principal objectif est de fournir une structure solide aux composants. Chaque composant à ainsi un rôle et un emplacement précis au sein de notre architecture.

Le Schéma

Dans le schéma, et dans l’injecteur de dépendances en général, un « service»  est un objet qui est géré par le conteneur.

Le schéma représente les liens entre les différents services. Il décrit les dépendances de nos objets.

Si vous connaissez le patron de conception de fabrique abstraite, vous pouvez vous représenter le schéma comme une configuration alors que le conteneur serait la fabrique elle même (ou quelque chose d’approchant).

Le schéma contient toutes les informations sur les méthodes qui doivent êtres appelées pour injecter les objets, le type des arguments qui doivent être passés, et tout autre type d’information potentiellement utile au moment de l’injection.

Pour en revenir à notre exemple, le schéma contiendrait des informations sur le type de glace qui doit être passée à Alice (Une glace à la fraise bien sur!), et sur la manière de donner cette glace à Alice (via la méthodesetGlace())

Jusqu’à maintenant, nous avons parlé de dépendances simples, mais le schéma peut aussi gérer d’autres types de services, méthodes et arguments. Tout est décrit dans les sections suivantes:Services,MethodsetAttibutes.

Services

Un service représente un objet. Dans notre exemple, la Glace et Alice sont des services.

Un service se compose d’:

• un nom
• un ensemble de méthodes
• une manière de se construire
• une portée (scope)

La portée d’un service définit comment la durée de vie des services doit être gérée par le conteneur: Est-ce que le service doit rester dans le conteneur pendant toute la durée du script (singleton), ou doit il être systématiquement supprimé après avoir été construit (prototype)?

L’instance de l’objet courant peut être la même pour l’ensemble des services si la portée du service est définie comme étant un singleton, ou être à chaque fois différente si la portée est définie comme prototype.

D’autres types de portées peuvent êtres imaginées comme une portée de « session» , qui retournerait la même instance durant une session unique, ou une sorte de portée « immortelle» , qui retournerait toujours le même objet, en faisant persister cet objet à travers différentes sessions.

L’injecteur de dépendances est fourni avec les types de service suivants:

Défaut : Un service « simple» , composé de méthodes, et qui peut être construit comment un simple objet.

Alias : Un alias vers un autre service. Seul le nom est différent. Ce type de service permet de gérer facilement les dépendances dans le temps. « Pour le moment, il s’agit d’un alias, mais peut être qu’un jour nous aurons besoin d’un autre type de service» .

Héritage de services : Plutôt que de se répéter maintes et maintes fois lors de la description de services qui se ressemblent, il est possible d’utiliser l’héritage. Cela ressemble grandement à l’héritage de classes: les méthodes que vous redéfinissez ou ajoutez dans les services enfants écraseront ceux des parents.

Méthodes

Chaque service contient des méthodes.

Une méthode permet d’injecter certains paramètres dans nos services, ou de définir certaines ressources qui doivent être appelées au moment de la construction des services. Dans le cas d’Alice,setGlace()est une méthode.

Une méthode est composée d’:

• un nom,
• optionellement, un nom de classe
• une liste d’arguments
• une information disant si la méthode est statique ou non

Voici les différents types de méthodes actuellement implémentées:

Défaut : Une simple méthode, avec des arguments. Peut être une méthode statique

Attributs : Utilisé pour régler directement les propriétés en utilisant les attributs publics de l’objet ($service->attribut = $valeur`). Ce type de méthode peut contenir uniquement un argument. Il peut paraître étrange de gérer les attributs comme des méthodes. En réalité, il est important de comprendre la différence entre une méthode et un argument. Alors qu’un argument représente une valeur, une méthode représente une manière d’utiliser ces arguments. Dès lors, il parait plus logique de gérer les attributs comme des méthodes que comme des arguments.

Rappels (callbacks) : Avant ou après la création de vos services, il est possible d’appeler des méthodes spécifiques, appelées méthodes de rappel.

Arguments

Les méthodes contiennent donc des arguments, et il existe plusieurs types d’arguments également.
Les arguments sont le bout de la chaine services / méthodes / arguments.

Défaut : Types PHP natifs (int, string, float etc)

Conteneur : Il est possible d’injecter directement le conteneur. Ce type d’argument n’est utilisé que par les services qui nécessitent d’utiliser le conteneur. Ils sont appelées services « ContainerAware» .

Service courant : Il est possible d’injecter le service en cours, et de l’utiliser comme argument. En pratique, ceci est uniquement utile pour les méthodes de rappel (callback)

Argument vide : Il s’agit d’un type d’argument qui na pas de valeur. L’argument « conteneur»  et « service courant»  étendent ce type. Attention, l’argument vide est différent de null.

Référence à un service : C’est un des types d’argument le plus utilisé, il représente un autre service.

Argument résolu grâce aux services : Parfois, il est utile d’utiliser un service pour récupérer un argument, je pense à la configuration entres autres. Ce type d’argument utilise donc une méthode spécifique d’un autre service pour être résolu.

Stratégies de construction

Maintenant que nous avons un schéma qui représente les relations entre nos services, nous allons nous occuper de la construction de ces services.

Nous avons choisi de séparer complètement les logiques de construction et de définition, pour permettre de favoriser un maximum d’usages possibles pour l’un et l’autre des composants.

Chaque type, dans le schéma, peut être lié à un type de stratégie pour se construire. Il y à donc plusieurs stratégies de construction pour les services, les méthodes et les arguments.

L’intérêt d’utiliser des stratégies de construction est de permettre à chacun de nos types, dans le schéma, de se construire eux même, en utilisant leur méthodebuild(), qui va elle déléguer la tache de construction aux stratégies.

En interne, il est possible d’utiliser des stratégies de construction différentes, et d’en changer à tout moment. Ce comportement suit, en fait, le patron de conception stratégie.

Builders / Monteurs

Puisque nous parlons de patrons de conception (design patterns), parlons du motif « Monteur» .

Vous serez sans doute d’accord avec moi pour dire qu’écrire un schéma entièrement à la main, en utilisant les classes dont nous avons parlé un peu plus haut peut s’avérer rapidement assez pénible. En tout cas, pour l’avoir expérimenté lors de l’écriture des tests, je peux dire qu’il ne s’agit pas d’un gain de temps, loin de là.

Une solution pratique consiste à utiliser le motif Monteur. L’idée est d’écrire le schéma sous une forme sympathique et facile à écrire pour nous, développeurs, et d’utiliser une classe intermédiaire pour transformer notre représentation du schéma dans la représentation compréhensible par notre composant.

Cette classe intermédiaire monte donc notre schéma, en déchiffrant une autre structure.

Le premier type de monteur qui me vient à l’esprit (le plus pratique, en fait), est le monteur XML. Il est capable de lire un schéma, décrit au format XML, et de construire le schéma en utilisant les objets de notre bibliothèque. L’écriture du schéma XML à plusieurs avantages: il est facile à écrire, permet d’utiliser des outils extérieurs pour l’éditer facilement, et bénéficie, grâce a XML Schema, d’une auto-complétion et d’une vérification à la volée, lors de l’écriture.

Les injecteurs de dépendances Google Juice et Spring permettent l’utilisation des annotations directement dans le code, pour définir les règles d’injection (le schéma pour nous).

Bien qu’il ne s’agisse pas d’un comportement recommandé (les annotations ne sont exploitables que par un type d’injecteur, même si une spécification est actuellement en cours), il est possible d’utiliser la réflexion sur un projet, et de la combiner a l’utilisation d’annotations pour déduire facilement la structure de notre schéma, pour le remplir ensuite à notre guise.

Ce composant est également un monteur.

Les monteurs suivants sont fournis de base:

• Le monteur XML
• Le monteur PHP, qui utilise une interface fluide, pour permettre des configurations de ce type:$monteur->addService()->withMethod()
• Le monteur Réflexion (utilise la réflexion sur nos classes pour construire un schéma)

Dumpers

Un dumper est un objet qui copie des données d’un type de format vers un autre. Effectivement, il peut s’avérer utile d’avoir une manière simple de se représenter un schéma déjà défini.

Les dumpers permettent par exemple de représenter un schéma sous une forme graphique, ou bien sous une forme plus compréhensible pour nous, avec un simple texte par exemple.

Il est donc vraiment facile de montrer les dépendances de vos projets, en utilisant simplement le dumper Dot (qui est le format utilisé par graphviz) par exemple.

Voici la liste des dumpers :

• Le dumper texte
• Le dumper Dot (graphviz)
• Le dumper XML
• Le dumper PHP

Ces deux composants laissent entrevoir des pistes intéressantes: il est possible d’écrire ses classes, puis de générer un schéma partiel grâce au monteur « réflexion» , de le dumper en XML, de le compléter à la main (avec de l’auto-complétion), et de le monter à nouveau, grâce au monteur XML.

Implémentation

Voici quelques règles que nous avons suivi lors du développement en lui même:

Espaces de noms / PHP 5.3

Alors que nous nous penchions sur ce projet, PHP 5.3 n’était pas encore sorti, mais puisque cette version apportait des fonctionnalités vraiment intéressantes (late static binding, espaces de noms et closures), nous avons choisi d’utiliser alors la version en cours de développement de PHP 5.3.

Maintenant, PHP 5.3 est disponible en version stable, et permet de faire fonctionner notre projet.

Notre bibliothèque se sépare selon les espaces de noms suivants:

• L’espace de nomConstruction, qui contient toutes les classes liées au concept de construction (les stratégies de construction)
• L’espace de nomDefinition, qui contient le schéma.
• L’espace de nomTransformationqui contient les Dumpers et les Monteurs

Développement piloté par les tests (TDD)

Ce projet fut également l’occasion d’écrire nos premiers tests, pour finir par utiliser une approche pilotée par les tests.

Le développement piloté par les tests préconise de réaliser ses tests avant d’écrire ses classes. Au début, ça chatouille un peu, mais on comprend rapidement l’intérêt de cette méthodologie, qui est une vraie bonne pratique.

Écrire ses tests avant d’avoir codé la classe nous oblige à la fois à privilégier une utilisation logique de nos composants, et à fixer les interfaces. Le code produit est réellement comme on souhaite l’utiliser, et non pas comme il est plus facile de l’implémenter.

Écrire des tests, c’est aussi penser à l’ensemble des scénarios d’utilisation de ces classes, même les plus farfelus. Cela nous oblige à réfléchir à tous ces cas d’utilisation, et ça fait le plus grand bien !

Pour revenir aux tests, ils permettent de tester que notre application se comporte bien comme elle le devrait, mais cela permet aussi de détecter rapidement des régressions que de nouvelles fonctionnalités peuvent apporter.

Rapidement, on écrit des tests pour tout: bugs, idées, etc. Ça favorise vraiment le développement d’une application.

Un peu plus haut, je parlais de Mock objets (ou objets bouchon, en français). Je vous laisse consulter l’article wikipédia sur les mocks pour vous faire une idée plus précise, mais il s’agit, rapidement, d’objets qui permettent de simuler le comportement d’autres objets, ces derniers pouvant communiquer avec la suite de tests.

Interfaces

Dans l’ensemble de nos classes, nous essayons d’utiliser des interfaces plutôt que des implémentations particulières.
Pourquoi ? Parce que travailler avec des interfaces nous permet de changer à tout moment d’implémentation !

Dans le cas d’Alice, elle n’est pas dépendante d’un type particulier de glace (celle à la fraise), mais simplement aux glaces, à l’interfaceGlace, pour être exact.

Chacune des interfaces ci dessous représente un comportement décrit plus haut:

• Schema
• Service
• Method
• Argument
• Container
• Dumper
• Builder

L’écriture des classes

Pour écrire nos classes, et parce que nous souhaitons fournir un système facilement extensible, nous fournissons quasi systématiquement une interface, et une classe abstraite, pour que chaque concept puisse être étendu facilement.

D’ailleurs, l’écriture des classes en elle même est assez simple, une fois que tous les concepts ont étés décrit et sont clairs.

Vous pouvez regarder le code sur le dépôt mercurial de spiral

Je ne vois pas grand chose à ajouter à propos de l’implémentation, si ce n’est, peut être, qu’il est indispensable de commenter votre code: cela permet aux potentiels futur contributeurs de s’y retrouver facilement, et de comprendre le détail des opérations !

Conclusion

J’espère que cet article vous aura intéressé, en tout cas j’ai pris beaucoup de plaisir à l’écrire, et vous aurez au moins appris comment nous avons choisi d’implémenter un injecteur de dépendances en utilisant quelques bonnes pratiques logicielles !

I’ll try do sum-up my general feelings here, and the work I’ve made so far. You can also find, if you’re interested, my weekly summaries in a dedicated wiki page.

Yesterday, as I was traveling to Tours, I’ve took some time to visit Éric, another student who’s working on distutils2 this summer, as a part of the GSoC. Basically, it was to take a drink, discuss a bit about distutils2, our respective tasks and general feelings, and to put a face on a pseudonym.

I’d really enjoyed this time, because Éric knows a lot of things about mercurial and python good practices, and I’m eager to learn about those.

So, we have discussed about things, have not wrote so much code, but have some things to propose so far, about documentation, and I also provides here some bribes of conversations we had.

Thanks a lot to all the presents for being there, it was a pleasure to talk about this topic with you. Too bad the season is over now an I quit Toulouse next year.

During our brainstorming about the topic, we used some paper, and we wanted to make a presentation the simpler way.

First thing that come to my mind was using restructured text, so I’ve wrote a simple file containing our different bullet points.

In fact, there is quite nothing to do then, to have a working presentation.
So far, I’ve used the rst2pdf program, and a simple template, to generate output.

It’s probably simple to have similar results using latex + beamer, I’ll try this next time, but as I’m not familiar with latex syntax, restructured text was a great option.

Here are the final PDF output, Rhe ReST source, the theme used, and the command line to generate the PDF:

As my courses are not over yet, I’ve not worked as much as I wanted, and this will continues until the end of June. My main tasks are about making installation and uninstallation commands, to have a simple way to install distributions via Distutils2.

To do this, we need to rely on informations provided by the Python Package Index (PyPI), and there is at least two ways to retreive informations from here: XML-RPC and the "simple" API.

So, I’ve been working on porting some Distribute related stuff to Distutils2, cutting off all non distutils’ things, as we do not want to depend from Distribute’s internals. My main work has been about reading the whole code, writing tests about this and making those tests possible.

In fact, there was a need of a pypi mocked server, and, after reading and introducing myself to the distutils behaviors and code, I’ve taken some time to improve the work Konrad makes about this mock.

I’ve been accepted to be a part of the Google Summer Of Code program, and will work on python distutils2, with a lot of (intersting!) people.

So, it’s about building the successor of Distutils2, ie. « the python package manager» . Today, there is too many ways to package a python application (pip, setuptools, distribute, distutils, etc.) so there is a huge effort to make in order to make all this packaging stuff interoperable, as pointed out by the PEP 376.

In more details, I’m going to work on the Installer / Uninstaller features of Distutils2, and on a PyPI XML-RPC client for distutils2.

Here are the already defined tasks:

• Implement Distutils2 APIs described in PEP 376.
• Add the uninstall command.
• think about a basic installer / uninstaller script. (with deps) — similar to pip/easy_install
• in a pypi subpackage;
• Integrate a module similar to setuptools’ package_index’
• PyPI XML-RPC client for distutils 2: http://bugs.python.org/issue8190

As I’m relatively new to python, I’ll need some extra work in order to apply all good practice, among other things that can make a developper-life joyful.

I’ll post here, each week, my advancement, and my tought about python and especialy python packaging world.

Après un répis d’une semaine, pour récupérer des folies organisatrices (c’est ça qui fait du bien, ceci dit — les folies, pas le repos), je me retrouve de nouveau sur ces mêms réflexions, grâce aux journées organisées par France Nature Environnement, qui proposaient ce jeudi soir une projection de "Le temps des grâces", un documentaire sur l’agriculture.

Parce que depuis 60 ans, il est pratiqué le remembrement des parcelles à gogo, parce que nos sols deviennent completement morts à cause des tonnes d’intrants qu’on leur fait absorber, et parce que les exploitations s’agrandissent sans en finir pour tenter de réagir façe à un marché financier toujours plus insaisissable, mené de très loin par la PAC, il fallait un film pour en parler.

C’est ce que fait "le temps des grâçes", avec un bon sens et une facilité à faire passer des messages, qu’on ne peut qu’applaudir. Malheureusement il s’agissait de la dernière diffusion à L’Utopia de Toulouse… Si vous en avez l’occasion, sautez dessus et profitez le temps de ces 2 heures, ou vous pourrez écouter à la fois des discours d’agronomes, d’agriculteurs, de chercheurs et bien d’autres, qui dressent un constat pas si brillant de notre agriculture. On n’est pas sorti de l’auberge, enfin, c’est l’expression.

Je vous laisse avec le synopsis et une bande annonce.

Une enquête documentaire sur le monde agricole français aujourd’hui à travers de nombreux récits : agriculteurs, chercheurs, agronomes, écrivains… Un monde qui parvient à résister aux bouleversements qui le frappent – économiques, scientifiques, sociaux – et qui, bon gré mal gré, continue d’entretenir les liens entre générations. Un monde au centre d’interrogations majeures sur l’avenir.

Ainsi qu’un commentaire que je ne peux m’empécher de relayer, trouvé sur allocine.fr (oui, vous savez, ce site rempli de pubs).

Le temps des grâces c’est je pense le plus grand film traitant de l’écologie en tant que documentaire ou en sujet principal, on y apprend une multitude de choses, on en ressort en colère contre le système, le film propose différents points de vues, ici on a pas de voix off moralisatrice à deux balles avec des gros titres bien surlignés pour que même les beaufs matant TF1 puissent comprendre, ici même si ça reste accessible au citoyen lambda, le film ne fait pas de compromis avec le monde agroalimentaire, il ose dénoncer les filière d’agronomie qui apprennent pas les bonnes choses à leurs étudiants, aux lobbys de cette agro-industrie qui n’en fait qu’à sa tête pour amasser de l’argent, cette tendance à tout uniformiser et détruire… Franchement j’ai trouvé ça génial de bout en bout, captivant, on explore cette campagne française, on comprend les dilemmes des paysants. Le film n’étant pas opposé à la modernité, ni même réactionnaire, il propose juste un constat alarmant du monde agricole français, tout en proposant des alternatives qui pourraient être utilisée, si les pouvoirs publics lâchaient un peu la main des lobbys. Passionnant, vraiment.

Courrez-y, je vous dis.

D’un autre coté, des projets matures et fiables voient le jour, héritant du savoir faire et de la qualité du monde Java, un exemple frappant est Flow3, et plus récemment, Symfony 2 (ce qui m’à d’ailleurs agréablement surpris). Le monde de PHP est donc en pleine mutation, avec la montée en puissance de concepts avancés tels l’inversion de contrôle, les tests unitaires et (enfin!), de la VRAIE persistance.

A l’origine, un langage de débutants…

Ce qui plombe le plus PHP, doit être le non professionnalisme d’une partie de sa communauté, découvrant le développement via PHP — langage permissif au possible — et laissant la porte ouverte à des aberrations folles.

Le langage laisse (trop) libre les nouveaux venus, et on ne parles que peu de tests unitaires, de code commenté (j’en passe des tonnes, volontairement). Facile donc de faire les choses de travers, et vous ne trouverez que peu de personnes pour vous encourager à ne pas continuer dans ce sens, à moins de savoir vers ou chercher.

On trouve encore trop de scripts en PHP avec une approche fonctionnelle (de par le passé de php et son approche fonctionnelle de la programmation), et trop de bibliothèques pas ou peu testées, bref, dans l’ensemble c’est une catastrophe. Je m’amuse à faire l’analogie avec la construction de maisons avec du scotch.

… qui tends à se professionnaliser

Je suis le premier à dire que les (petites) entreprises (en général) manquent d’un savoir faire crucial en terme de bonnes pratiques, et pourtant, ces dernières commencent à s’intéresser de près à des concepts avancés, et aux bonnes pratiques. Les frameworks utilisés en entreprise sont souvent testés unitairement (Jelix, symfony, Zend Framework, pour ceux que j’ai eu l’occasion d’apprivoiser), et les bonnes pratiques sont parfois vraiment mises en avant.

Avec la sortie de PHP 5.3, on peut désormais utiliser des fonctionnalités telles que les espaces de noms ou les closures, concepts déjà implémentés depuis fort longtemps dans d’autres langages, et qui venaient à briller par leur absence.

Et un front de raz-le-bol général qui bat son plein: on veut du code testé, du code bien fait, on en veux plus de la soupe (et de la programmation spaghetti) ! Rébellion !

Même si je fonde de grands espoirs dans PHP, et que je penses que tout n’est pas à jeter, qu’il y à une réelle motivation qui commence à se faire sentir de la part de la communauté, je me demandes si PHP joue dans la même cour que Java, ou que Python et Ruby pour ne citer qu’eux, qui bénéficient d’une communauté forte et avide de bonnes pratiques.

Et vous qui utilisez PHP, vous en pensez quoi ? PHP peut-il être comparé à Java, à Python, à Ruby ? Est-ce une abération de faire de telles comparaisons? ou est-ce définitivement à un autre niveau ?

Dans cette optique, depuis près de 3 ans (déjà !), au sein du réseau GRAPPE, on essaye d’aborder des thématiques qui touchent de près ou de loin à l’environnement, parce que c’est un sujet qui nous importe et nous passionne.

L’année dernière, c’était l’alimentation étudiante, ce qui à abouti à la publication de la revue « les étudiants se mettent à table» . Cette année c’est la consommation étudiante qui est au programme.

La consommation étudiante ?

L’idée principale de cette étude est de tenter de faire une analyse de la « société de consommation» , souvent questionnée par les étudiants et par d’autres, et de jeter un œil sur le rapport des étudiants à cette société:

Quoi et comment consomment-ils ? Les universités et les écoles ne poussent-elles pas d’une certaine manière les étudiants à la consommation ?

Quelles sont les alternatives face aux dérives de surconsommation ?

Analyse des pratiques, réflexions et mobilisations des étudiants en termes de consommation seront réalisés pour comprendre leur modes de vie, mais aussi leurs attentes, leurs propositions sur cette thématique

La semaine de l’environnement !

A travers l’ensemble des villes du réseau, des projections de films et des débats auront donc lieu sur ce thème, lors de la semaine de l’environnement 2010, qui se déroulera d’ailleurs durant le mois de Mars partout en france, et du 6 au 14 Mars sur Toulouse. Jetez un oeil au programme !

Avec pour objectif de sonder un peu le ressenti des étudiants en terme de consommation, nous avons mis en place un questionnaire en ligne, que vous pouvez compléter en une petite 10aine de minutes, n’hésitez pas !

La page sur la consommation étudiante sur le site du GRAPPE

Je prends un plaisir non dissimulé à découvrir ce langage (et à l’utiliser), qui ne cesse de me surprendre. Les premiers mots qui me viennent à l’esprit à propos de Python, sont « logique»  et « simple» . Et pourtant puissant pour autant.

Je ne manque d’ailleurs pas une occasion pour faire un peu d’évangélisation auprès des quelques personnes qui veulent bien m’écouter.

The Zen of Python

Avant toute autre chose, je pense utile de citer Tim Peters, et le PEP20, qui constituent une très bonne introduction au langage, qui prends la forme d’un easter egg présent dans python:

J’ai la vague impression que c’est ce que j’ai toujours cherché à faire en PHP, et particulièrement dans le framework Spiral, mais en ajoutant ces concepts dans une sur-couche au langage.

Ici, c’est directement de l’esprit de python qu’il s’agit, ce qui signifie que la plupart des bibliothèques python suivent ces concepts. Elle est pas belle la vie ?

Comment commencer, et par ou ?

Pour ma part, j’ai commencé par la lecture de quelques livres et articles intéressants, qui constituent une bonne entrée en matière sur le sujet (La liste n’est bien évidemment pas exhaustive et vos commentaires sont les bienvenus) :

• Dive into python
• A byte of python
• Python: petit guide à l’usage du développeur agile de Tarek Ziadé
• La documentation officielle python, bien sûr !
• Les vidéos du pyconfr 2009 !
• Un peu de temps, et une console python ouverte

J’essaye par ailleurs de partager au maximum les ressources que je trouve de temps à autres, que ce soit via twitter ou via mon compte delicious. Allez jeter un œil au tag python sur mon profil, peut être que vous trouverez des choses intéressantes, qui sait!

Un python sexy

Quelques fonctionnalités qui devraient vous mettre l’eau à la bouche:

• Le chaînage des opérateurs de comparaison est possible (a<b <c dans une condition)
• Assignation de valeurs multiples (il est possible de faire a,b,c = 1,2,3 par exemple)
• Les listes sont simples à manipuler !
• Les list comprehension, ou comment faire des opérations complexes sur les listes, de manière simple.
• Les doctests: ou comment faire des tests directement dans la documentation de vos classes, tout en la documentant avec de vrais exemples.
• Les métaclasses, ou comment contrôler la manière dont les classes se construisent
• Python est un langage à typage fort dynamique: c’est ce qui m’agaçait avec PHP qui est un langage à typage faible dynamique.

Cous pouvez également aller regarder l’atelier donné par Victor Stinner durant le Pyconfr 09.

Have fun !