Since my previous article (FR), I have kept on working on the dependencies injector of Spiral, wich I just published in a standalone version.

Here is an overview of SpiralDi functionnalities, and some examples on the use.

Table des matières

Overview

SpiralDi comes with a lot of new features, some of them inspired by the excellent Java framework : Spring. It is now possible to :

• Use factories to set the parameters values (useful for configuration)
• Use an inheritance system to make configuration file more clear
• Use factories for the construction of the services
• Directly inject the container in ContainerAware services

But, maybe, it doesn’t mean anything for you ? I will explain the details further later.

Principles

If you don’t know much about the inversion of control, I advise you to read my introduction on the dependencies injection (FR).

The use of a lightweight container is done in two steps :

• The description of the schema of all the services that will be used later
• The call (so, the construction) of these services via the container

The SpiralDi library let you describe the Schema in different ways. The sexiest is probably the XML description file, but it is also possible to define this Schema using the PHP language if you think it’s more convenient. The following examples are in XML. Here is a quite simple definition file, that describe two services :

Once this file is written, you have to transform it in a SpiralDi understandable format : the Schema.

You can now exploit the built Schema. The Schema is first used to resolve objects. We will see later that it has much more aims. Now, pass this Schema to the Container :

This looks sexy, isn’t it ? The container has done everything ! Resolution of the object’s dependencies and injection of these dependencies when needed.

Services scope

All services constructed by SpiralDi have a controlled life time.
In the default behavior, the container will return the same instance of the object, each time the service is needed. This is the singleton scope.
All services are by default configured to have the singleton scope.

You can also use the prototype scope to make the container create a new instance each time the service is needed.

To change the scope of the service, you can use the property

in the XML file.

Advanced use

Now, you know how to describe « basic»  services and their dependencies. Let’s see now, more complex features.

Using references and MethodFactory

Sometimes, you will need to inject parameters in a dynamic manner. Imagine that you don’t know the value of a parameter that you want to inject because it is stored in a configuration object for example.

So, we want the container to construct our services using information from a Config object. The container is able to generate automatically the following code for us :

For this, we have to use the system of references :

It is also possible to specify the method that will be used to get arguments. For example

will produce something like this :

The corresponding XML code will be :

Inheriting and overloading services

Quite often, some services are similar. It is possible to use the inheritance system to make the services description lighter.
This is not an actual inheritance between classes, but only the inheritance principle. Thus, you can extend a service description, which make the description file more readable and easier to understand.

Container Aware

In some cases, services have to know the existence of the container, and need to access to it. It is easy to inject the container in a service by using the « container»  type or the facility « containerAware»  :

From the class’ point of view, you only have to implement the SpiralDi_ContainerAware interface. In this way, during the construction of the service, the setDiContainer method of your class will be automatically called.

As well, in this case, there is no need to explicitly name your service as « ContainerAware»  in the description file, the container will automatically detect it

Factories

SpiralDi also provides a convenient way to use Factories from the DI. This helps generating behaviors like :

The corresponding XML code is :

This should be nice if you want to reuse your old Singleton implementations, among other things…

Download it !

Convinced ? To get the latest version of SpiralDi, you have many solutions :

Via the mercurial repository

Via the archives

The code is available in the following formats : zip, gz ou bz2

You can also directly check the repository.

That’s all ! You can now have fun using it ! For functionnality requests, bug report, etc. Please !

Interesting readings

If you want to know more about dependencies injection, here are some interesting readings on the subject :

• Martin Fowler’s article on dependencies injection
• Fabien potencier’s suite of articles (1,2,3,4,5)
• Another one from Padraic Brady (1,2)
• Fabien Potencier has also published a di container that feet in a tweet. to see, just for fun

Going further ?

SpiralDi is of course not the only PHP lightweight container. Recently, a lot of container are flowering on the web. Frameworks like Symfony and Flow3¹ are giving a good place to DI. So much the better !

• Symfony’s services container
• Yadim
• Flow3 Objects
• Sphicy
• Phemto
• Seasar
• Garden
• Xyster
• Lion

1. It is new, beautiful, written for PHP 5.3, using AOP, Domain Model persistence… and of course dependencies injection ! Keep an eye on it : Flow3

Suite à mon précédent article, j’ai continué à travailler sur l’injecteur de dépendances de Spiral, que je viens de publier dans une version standalone.

Voici un tour d’horizon des fonctionnalités apportées par SpiralDi, ainsi que quelques exemples d’utilisation.

Table des matières

Tour d’horizon

SpiralDi arrive avec son lot de nouveautés, pour certaines inspirées de l’excellent framework Java Spring. Il est désormais possible, en vrac, de:

• Utiliser des factories pour renseigner les valeurs des parametres (pratique pour la configuration)
• Utiliser un système d’héritage, pour alléger les fichiers de configuration
• Utiliser des Factories pour résoudre les services
• Injecter directement le conteneur à certains services, dits ContainerAware

Mais peut être que ça ne vous parles pas trop, nous y reviendrons tout à l’heure.

Principes

Si vous n’êtes pas à l’aise avec le principe d’inversion de contrôle, je vous conseille d’aller lire mon introduction sur l’injection de dépendances.

L’utilisation d’un conteneur léger se fait toujours en deux étapes:

• La description et le renseignement du schéma de services qui pourront être utilisés par la suite
• la demande de résolution de ces derniers, via le conteneur

SpiralDi fournit plusieurs manières de décrire le Schema. La plus appropriée est surement l’XML, mais il est également possible de passer via du PHP si cela vous semble plus pratique. Nous prendrons ici l’exemple du XML. Voici un fichier de description assez simple, qui décrit deux services:

Une fois le fichier écrit, il faut le transformer dans un format compréhensible par SpiralDi: le Schema.

Nous pouvons désormais exploiter notre Schema. La première utilité d’un Schéma est d’être utilisé pour résoudre nos objets. Nous verrons un peu plus tard qu’il peut avoir d’autres utilités. Passons donc le Schema au Conteneur:

Plutôt sympa non? Le conteneur s’est occupé de tout: résolution des dépendances de l’objet, et injection de ces dernières quand nécessaire.

Portée des services (Scopes)

Les services construits via SpiralDi ont une durée de vie contrôlée.
Par défaut, plusieurs demandes au conteneur pour un même service retournerons la même instance de l’objet, il s’agit de la portée de type singleton.
Le conteneur est configuré par défaut pour que les services qu’ils crée aient une portée de type singleton.

Il est possible d’utiliser la portée prototype pour qu’un nouvel objet soit créé à chaque appel du service, en utilisant la propriété

dans le fichier XML.

Utilisation « avancée» 

Vous savez désormais comment décrire « basiquement»  vos services et leurs dépendances. Voyons maintenant quelques concepts un peu plus poussés.

Utilisation des Références et des MethodFactory

Il peut arriver que l’on ai besoin d’injecter des paramètres de manière dynamique. Imaginez que vous ne connaissiez pas la valeur des paramètres à injecter, ceux-ci étant contenus dans un objet de configuration par exemple.

Nous souhaitons donc que le conteneur construise nos objets en utilisant des informations contenues dans la configuration. Le conteneur est donc capable de s’occuper de générer le code suivant à notre place:

Pour cela, il faut utiliser le système de réferences:

Il est également possible de spécifier la méthode à utiliser pour résoudre les arguments,

par exemple, pour arriver à quelque chose de ce genre:

Le code XML est alors le suivant:

Héritage et surcharge de services

Assez souvent, certains services à injecter se ressemblent. Il est possible d’utiliser un système d’héritage pour rendre la description des services moins rébarbative. Il ne s’agit pas d’un héritage « concret»  dans nos classes, mais du principe de l’héritage. Ainsi, une description peut en étendre une autre, facilitant à la fois son écriture et sa compréhension.

Container Aware

Dans certains cas, il peut être utile qu’un service soit conscient de l’existence du conteneur, et qu’il puisse y accéder. Il est facile d’injecter le conteneur dans un service, en utilisant le type « container» , ou la facilité « containerAware» :

Du coté de votre classe, si celle-ci doit récupérer le conteneur, elle à simplement à implémenter l’interface SpiralDi_ContainerAware. Lors de sa construction, la méthode setDiContainer sera directement appelée.

A noter que dans ce cas, il n’est pas nécessaire de définir votre service comme étant « ContainerAware» , le conteneur étant capable de le découvrir tout seul.

Factories

Il est également possible d’utiliser des Factory depuis le DI, pour générer un comportement comme celui ci

Le code XML correspondant est le suivant:

Cela peut s’avérer pratique pour récupérer vos anciennes implémentations du pattern Singleton entres autres…

Téléchargez le !

Convaincu ? Pour récupérer la dernière version de SpiralDi, vous avez le choix entre plusieurs solutions:

Via le dépôt mercurial

Via les archives

Le code est disponible en zip, gz ou bz2

Vous pouvez aussi aller jeter directement un oeil au dépot.
Et voila! Vous avez de quoi vous amuser ! Pour toute demande de fonctionnalité, rapport de bug etc, n’hésitez surtout pas!

Et ailleurs ?

SpiralDi n’est bien évidemment pas le seul Conteneur Léger écrit en PHP. Depuis peu, ces derniers commencent d’ailleurs à fleurir sur la toile. Les frameworks Symfony et Flow3¹ leur font d’ailleurs la part belle, et c’est tant mieux! Quelques alternatives possibles au conteneur de Spiral donc:

• Le service container de symfony
• Yadim
• Flow3 Objects
• Sphicy

Lectures intéressantes

Si vous souhaitez aller plus loin, voici quelques lectures intéressantes sur le sujet de l’injection de dépendances:

• L’article de Martin Fowler sur l’injection de dépendances
• La série d’articles de Fabien potencier (1,2,3,4,5)
• Celle de Padraic Brady (1,2)
• Les conteneurs légers du futur, par Sami Jabber

1. Il est tout nouveau, tout beau, en PHP 5.3, utilise l’AOP, la persistance Domain Model … et l’injection de dépendances! A suivre de très près: Flow3

Avant tout, il faut bien comprendre que sans contexte il n’existe pas de manière plus censée qu’une autre pour construire une application. Il existe par contre un ensemble de bonnes pratiques qu’il est bon de connaitre et d’appliquer, dans la plus large mesure possible. Ces pratiques sont souvent mal connues, et nombre d’entre elles sont appliquées à la va vite.

Nous allons tenter d’expliquer ici pourquoi et comment l’implémentation la plus rependue du singleton favorise la création de dépendances, et comment nous pouvons y remédier, grâce à l’injection de dépendances.

Le singleton

Le singleton, à l'origine de dépendances

Le Singleton est un patron de conception (souvent le premier patron de conception qui nous est présenté) qui doit être appliqué avec précaution. Son utilisation est souvent mal comprise et celui ci peut être considéré à tort comme une solution « miracle»  pour accéder facilement à un objet, comme on le ferait d’une variable globale. On dit d’ailleurs aussi qu’il s’agit de l’antipattern singleton, à raison. Pourquoi ?

Très rapidement, un singleton est une classe dont il existe un nombre défini d’instances. Typiquement, le singleton est utilisé afin de réduire le nombre possible d’instances d’une classe à une seule. Cela peut être très utile, et est utilisé dans de nombreux cas à bon escient (je pense par exemple à l’accès à une base de données).

Un des défauts majeur de ce motif, est l’implémentation la plus souvent présentée, qui va de paire avec l’usage de méthodes statiques pour récupérer une instance de la classe. Pour mieux comprendre, voici l’implémentation type, en PHP (le motif est sensiblement le même dans de nombreux langages):

Ici, pour récupérer l’instance de la classe, il est nécessaire de faire appel à la méthode statique getInstance de la classe DbConnection_Mysql.

Il est alors nécessaire, dans la classe utilisatrice du singleton (imaginons qu’il s’agisse d’une classe User), de hardcoder le nom de la classe DbConnection_Mysql, la classe A devenant alors dépendante de cette implémentation particulière du singleton.

Avec cette implémentation, il est impossible de changer la classe en charge de la connexion à la base de données sans modifier le code. Imaginons que nous souhaitons utiliser la classe DbConnection_Oracle par exemple, nous sommes bloqués. Il s’agit d’une problème de conception, et peut faire perdre un temps important lors du développement.

Inversion de contrôle / Injection de dépendances

Comme nous venons de le voir, le singleton, ou plutôt, cette implémentation du singleton, introduit et favorise les dépendances entre nos classes.

Une des solutions possible est d’inverser le flux de contrôle de notre application: au lieu que ce soit la classe User qui appelle directement DbConnection_Mysql, celui ci peut être crée en amont, pour être ensuite injecté dans la classe qui souhaite l’utiliser. De cette manière, Ce principe à un nom, il s’agit de l’injection de dépendances.

Théorie

Alice a besoin d’une Glace pour la manger().
Alice aime les GlaceALaFraise… Si on donne de l’argent à Alice elle achète systématiquement une GlaceALaFraise. Alice est bloquée au seul parfum « fraise des bois»  aussi savoureux soit-il.

Pour lui faire découvrir de nouvelles saveurs sa Maman décide de ne plus laisser Alice choisir sa Glace elle-même, mais se charge de choisir pour elle une GlaceAuPaté.

Quels que soit les goûts d’Alice, une GlaceAuPaté reste une Glace, et donc Alice est tout à fait à même de la manger()¹.

Le concept exposé ici est connu comme le principe d’Holywood: « Ne vous appelez pas vous même, nous vous appellerons» .

Ce qu’il faut retenir, c’est qu’Alice peut, si elle le souhaite, manger() tout type de Glace, même si au départ Alice n’à besoin de manger() q’une GlaceALaFraise. Nous favorisons ici la réutilisations du code: nous pouvons réutiliser Alice facilement et substituer sa Glace par une autre facilement.

Application à notre exemple

Reprenons l’exemple des utilisateurs et de l’utilisation de la DbConnection pour y appliquer ce principe d’inversion de contrôle. Notre code ressemblerait alors à quelque chose dans cet esprit:

Avec les deux interfaces/implémentations suivantes pour DbConnection et User:

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.

Nous avons parlé de singleton et de création de dépendances, mais l’injection de dépendances est applicable à tout type de classes, et devrait d’ailleurs être utilisé dans la plupart des projet d’importante envergure.

Utilisation d’un conteneur

schéma des dépendances entre nos classes

Pour aller un peu plus loin, il peut être utile et efficace de déléguer la tâche de création des objets à un conteneur. Il s’agit d’une classe, en charge de la création de tous les objets, ce dernier pouvant résoudre les dépendances nécessaires à la création de l’objet souhaité.

Nous avons donc le schéma de dépendances décrit à gauche. Une fois ces informations fournies au conteneur (via un fichier de configuration), nous pouvons facilement récupérer l’object User_Default en le demandant à notre conteneur:

. Ce dernier se charge alors de créer l’ensemble des dépendances de cet objet (un objet de la classe DbConnection_Mysql ici). Plutôt sympa, non ?

Pour faire en sorte que la classe d’accès aux données soit un singleton, c’est le schéma qu’il faut alors modifier (via le fichier de configuration ici.)

Ici, j’ai essentiellement parlé de dépendances entre classes. Cependant, de la même manière, il est possible de contrôler tous les arguments passés à nos objets, qu’il s’agisse de tableaux, de chaines de caractère ou autres.

Moi aussi j’en veux ! Spiral Di Container

Pour mon usage personnel, j’ai développé un injecteur de dépendances flexible, permettant d’appliquer ce modèle à mes futurs développements. Il existe déjà des projets similaires, mais ces derniers font un usage trop abusif – à mon gout – du mécanisme de réflexion, perdant alors grandement en performance.

Voyons comment nous pouvons utiliser le conteneur dans notre cas. Cela revient à créer le schéma de dépendances. Cela est possible pour le moment par 2 biais: via XML ou directement via php.

Directement via php

Via un fichier XML

Il est à noter que le fichier XML à été directement généré via le Dumper Xml, en utilisant le schema.

Si vous êtes interessé pour regarder plus en détail le fonctionnement de ce conteneur, les sources sont d’ores et déjà disponibles via le framework de travail spiral, disponible via son dépot mercurial.

L’injecteur de dépendances est présent dans la partie /core/Di de l’architecture. Une version standalone devrait bientôt voir le jour.

Si cet article vous à plu, je publierais prochainement une série d’article expliquant en détail comment utiliser un conteneur de dépendances, en m’appuyant sur des exemples concrets que j’ai pu rencontrer.

Ah, et j’oubliais, un grand merci aux relecteurs pour votre aide précieuse ! (Fred, David, Florent, Joel, Nico …)

1. Merci Frédéric pour ton super exemple !

Ayant besoin de garder une version de PHP 5.2 disponible, j’ai choisi d’installer PHP 5.3 en tant que CGI pour Apache. Rien de très compliqué, mais si je peux vous éviter de tourner en rond, voila comment j’ai procédé sur un système à base de debian (ubuntu ici).

On commence par télécharger la dernière archive sur snaps.php.net:

On l’extrait:

On compile ..

C’est quasiment prêt, les fichiers binaires ont étés crées dans /usr/local/bin/ , il ne reste plus qu’à activer le module actions pour apache (pour pouvoir utiliser les CGIs):

et à spécifier l’emplacement de nos cgis à Apache:

Voila, il ne vous reste plus qu’à relancer apache à coup de

et c’est parti !

Maintenant, pour utiliser PHP 5.3 au lieu de la version installée par défaut, il vous faudra créer un htaccess avec le contenu suivant:

A nous les joies de php 5.3 !

Je regroupe ici les résultats de mon étude, en espérant faire un petit état des lieux des différentes bibliothèques de génération de graphiques existantes, en tentant des les comparer. Volontairement, je ne désigne pas de meilleure bibliothèque, puisque cela dépends fortement du besoin qui l’accompagne.

J’ai tenté de faire un tour des bibliothèques qui me semblaient intéressantes, si toutefois vous connaissez une bibliothèque qui aurait sa place ici, je me ferais un plaisir de l’ajouter au comparatif.

Table des matières

Critères de comparaison

Ce comparatif se base sur les critères suivants:

• configuration (degré et facilité)
• Facilité d’ajout de nouveaux types de graphiques
• Qualité du code / maintenabilité
• les bibliothèques doivent êtres orienté objet
• générer les graphiques « coté»  serveur (pas d’application flash ou javascript donc)
• être encore maintenue par ses auteurs

Solutions existantes et descriptions

pChart

Descriptif

pChart est une bibliothèque php qui comporte 3 classes:

• pChart qui est en charge de construire les graphiques. Cette classe est fournie avec 2 types de methodes: celles qui permettent de créer directement des graphiques de haut niveau, et celles de bas niveau qui permettent de tracer les lignes, ellipses etc.
• pData est en charge de la gestion des données. Elle fournit un certain nombre de méthodes qui permettent la manipulation de données pour les graphiques.
• Un système de cache: pCache

Avantages

pChart fournit des graphiques de qualité, et une grande abstraction vis à vis des méthodes de bas niveau qu’elle offre. Par exemple, les méthodes fournies pour générer un graphique de type Pie sont parlantes. De plus, une bonne séparation des couches est faite: pData, pChart et pCache on chacun leur rôle et s’y tiennent.

Inconvénients

pChart n’est pas forcement pensé pour être étendu de la meilleure manière. Ainsi, pour ajouter de fonctionnalités de bas niveau par exemple, tel le changement de format du fichier de sortie, il faut réécrire les méthodes de la classe pChart afin qu’elles supportent ce nouveau format (ie. Il n’existe pas de système de « driver» ). Aussi, le code en lui même n’est pas beaucoup commenté, ce qui constitue un frein à la compréhension de celui ci. Par defaut, pChart ne gère pas le SVG.

Exemple

// Dataset definition
$DataSet = new pData();
$DataSet->AddPoint(array(10,2,3,5,3),'Serie1');
$DataSet->AddPoint(array('Jan','Feb','Mar','Apr','May'),'Serie2');
$DataSet->AddAllSeries();
$DataSet->SetAbsciseLabelSerie('Serie2');

// Initialise the graph
$Test = new pChart(300,200);
$Test->drawFilledRoundedRectangle(7,7,293,193,5,240,240,240);
$Test->drawRoundedRectangle(5,5,295,195,5,230,230,230);

// Draw the pie chart
$Test->setFontProperties('Fonts/tahoma.ttf',8);
$Test->drawFlatPieGraph($DataSet->GetData(),$DataSet->GetDataDescription(),120,100,60,PIE_PERCENTAGE,10);
$Test->drawPieLegend(230,15,$DataSet->GetData(),$DataSet->GetDataDescription(),250,250,250);

$Test->Render('example13.png');

phPlot

Descriptif

phPlot est une bibliothèque qui comporte une seule classe en charge de la génération des graphiques. Cette classe interagit avec l’extension php GD pour construire des graphiques. Les méthodes de cette classe sont là aussi séparés en méthode de bas et haut niveau.

Avantages

La bibliothèque tiens dans une seule classe, ce qui peut s’avérer pratique, une documentation exhaustive est fournie sur internet

Inconvénients

Étant basée sur GD pour la génération des graphiques, il est semble assez difficile de rajouter un format de sortie facilement: la solution n’est pas pensée pour être extensible à ce niveau là. La classe en question n’est pas facile à étendre ou modifier. De plus les graphiques rendus ne sont pas très esthétiques

Exemple

$plot = new PHPlot('300','200');
$data = array(
    array('Jan',10),
    array('Feb', 2),
    array('Mar', 3),
    array('Apr', 5),
    array('May', 3)
);
$plot->SetPlotType('pie');
$plot->SetDataType('text-data-single');
$plot->SetDataValues($data);
foreach ($data as $row)
  $plot->SetLegend(implode(': ', $row));

$plot->DrawGraph();

ezComponents: Graph

Descriptif

Les ezComponents sont des composants originellement utilisés pour la plate forme de publication ezPublish, mais visant dès le début à ne pas être dépendant de cette plate forme de publication. Les ezComponents forment à eux seuls un ensemble de briques logicielles prêtes à l’usage, un peu comme peut l’être le Zend Framework.

Avantages

Cette bibliothèque, ainsi que la totalité des ezComponents, vise à être utilisée sur des sites importants. Pour cette raison, un support existe sur ces solutions, et les composants seront probablement maintenus durant une période importante. L’ensemble des ezComponents est fourni avec une documentation très complète, des exemples, des tests unitaires, et un diagramme de classe (UML), qui indique que le code est réellement pensé orienté objet. Chaque classe à alors une utilisation bien précise, l’application étant réellement bien découplée. Cette bibliothèque est également fournie avec un support natif du SVG, grâce à un système de plugin de sortie. Par défaut, le système est prévu pour être extensible; ainsi, pour ajouter un nouveau type de graphique par exemple, l’utilisation du système d’héritage permet de gagner du temps. La configuration peut être très poussée en restant lisible.

Inconvénients

Tous les ezComponents ont une dépendance vis à vis de la classe ezBase. De plus, utiliser ce composant induit le chargement d’un grand nombre de classes, et donc de fichiers. Par défaut, ce composant n’as pas de système de cache. Il en existe par contre un dans les ezComponents. Etre complètement orienté objet peut aussi s’avérer être un inconvénient: une bibliothèque graphique peut être amenée à afficher un nombre important de valeurs. Cela signifie dans ce cas là, passer dans un nombre aussi important de méthodes et le temps de rendu peut s’avérer réellement long (voir la section benchmarks à la fin de cet article)

Exemple

// Create the graph
$graph = new ezcGraphPieChart();

// Add the data and hilight norwegian data set
$graph->data['months'] = new ezcGraphArrayDataSet( array(
    'Jan' => 10,
    'Feb' => 2,
    'Mar' => 3,
    'Apr' => 5,
    'May' => 3
));

// Modify pie chart label to only show amount and percent
$graph->options->label = '%3$.0f%%';
$graph->options->font->maxFontSize = 10	;

// legend
$graph->legend->landscapeSize = .3;

// Use 2d renderer, and beautify it
$graph->renderer = new ezcGraphRenderer2d();
$graph->renderer->options->dataBorder = false;
$graph->renderer->options->pieChartGleam = .3;
$graph->renderer->options->pieChartGleamColor = '#FFFFFF';
$graph->renderer->options->pieChartGleamBorder = 1;
$graph->renderer->options->showSymbol = false;  

// set colors
$graph->palette = new ezcGraphPaletteEz();

// Output the graph with std SVG driver
$graph->render( 300, 200, 'ezGraph.svg' );

Benchmarks

Maintenant ces différentes solutions sont présentées, il peut être intéressant de les comparer sur le plan rapidité. Voici un Petit comparatif au niveau rapidité. Si vous êtes curieux, vous pouvez télécharger les fichier source du benchmark.

Les différentes valeurs utilisées sont les suivantes: (width, height, values)

$configs['simple'] = array(400, 	300, 	range(0,10));
$configs['medium'] = array(500, 	500, 	range(0,100));
$configs['hard'] = array(1000, 1000, range(0,1000));
$configs['real'] = array(600, 200, include('_realData.php'));

Le fichier _realData.php contient retourne un tableau de quelques 1104 valeurs continues. Il se trouve aussi dans les sources disponibles plus haut.

Voici le résultat du test:

Tableau comparatif

	qualité du code	découplage	extensibilité	config (degré)	config (facilité)	qualité des graphs	temps de rendu	support du SVG
pChart
PHPlot
ezComponents

Récemment, j’ai été embauché en tant que stagiaire dans une petite boite qui fait du développement d’applications web (que je différencie de la réalisation de sites web). Cette société, basée à Paris, vient d’ouvrir des locaux sur Toulouse, et j’ai la joie et le plaisir d’en profiter. Je m’amuse vraiment, et découvre le Zend Framework, tout en passant toujours pour un extremiste qui déteste les antipatterns¹. Bref, une super équipe, des gens très interessants, et un stage de 6 mois qui débute très bien !

J’ai commencé les cours, après un mois de pré-cours intensifs². Et pour l’instant, ça me déplait plutôt. Il faut dire que les matières abordées ne s’y prétaient pas beaucoup (Microsoft et Oracle : merci bonsoir). La semaine qui arrive annonce le début des cours de Java, qui semblent bien plus prométeurs³. Espérons.

Qui l’eut cru: on à repris le développement de spiral, qui décidément porte très bien son nom, vu le temps depuis lequel le projet traine. Des deadlines sont fixées, les idées toujours aussi bonnes, et la motivation au rendez vous. Quelques nuit de travail en perspective, mais qu’est ce que c’est bon d’échanger sur des vrais sujets de geek developpeurs fans de design patterns !

Depuis mon arrivée à Toulouse, je fait partie d’une association naturaliste basée sur l’université de ramonville⁴, avec laquelle j’ai pu lancer un projet de semaine de l’environnement⁵. Ca me prends pas mal de temps, mais je rencontre des gens géniaux, et ça me fait décrocher de ce satané écran ! D’ailleurs, la semaine de l’environnement à non pas lieu dans une ville, mais dans 8, et les associations en question sont fédérées autour du GRAPPE (Groupement des Associations Porteuses de Projets en Environnement). Si vous aussi vous voulez lancer une semaine de l’environnement chez vous, contactez nous !

Plus recemment, nous avons eu l’idée de lancer une AMAP étdudiante sur Toulouse. Si vous êtes interessés, faites moi signe, les réunions approchent !

1. ou qui adore les patterns,au choix.
2. ou pas, tout dépends les matières
3. avis aux trolleurs multiples et potentiels: oui, je crois sincérement que Java, c’est bien. Un peu lent, mais bien! Peut être que l’avenir me contredira.
4. qui n’est pas du tout à coté de mon école…
5. une semaine d’activités autour du thème de l’environnement, qui aura lieu du 16 au 22 Mars 2009

Mais la rentrée pointe le bout de son nez (c’est une bonne chose!), et la reprise d’activités cérébrales ne devrait plus trop tarder. Comme d’habitude, petite liste des choses que j’aimerais bien faire cette année³

• J’ai eu l’occasion de découvrir l’excellent framework web Jelix, et de l’utiliser pour un projet (pas encore totalement terminé) web. Beaucoup de choses géniales, découverte de svn malgrès moi, et des tonnes d’idées à repiquer pour spiral en perspective⁴.
• Trouver un designer digne de ce nom, sur Toulouse, avec lequel travailler, parce que mes clients commencent à trouver que mes sites ont une sale gueule (et ils ont raison…)
• Trouver un vrai bouquin sur les designs patterns, en français, à mettre sur ma table de chevet.
• Et puis, enfin, m’installer et découvrir Toulouse, puisque j’ai la chance de poursuivre mes études la bas. D’ailleurs, si vous êtes du coin, je suis pour une visite grandeur nature!

Je profite de ce billet pour remercier ceux qui ont permis de faire de ma passion un gagne-pain le temps d’un été. L’expérience fut très enrichissante, et je vous en remercie chaleureusement.

1. 750km à vélo pour un mois de vacances inoubliable…
2. En savourant du Masada sous le grand chapiteau de Jazz In Marciac!
3. même si je sens que le temps va manquer…
4. malgrès la puissance de jelix, je continue à m’obstiner à faire « mon mien» . Question de fierté peut être ? En tout cas il me reste – beaucoup – à apprendre

C’est parce que GNU/Linux est une solution de plus en plus largement diffusée et accessible que beaucoup de nouveaux utilisateurs s’y essayent. Trop souvent en oubliant qu’il s’agit du résultat du labeur de la communauté Libre. C’est un phénomène qui se vérifie trop souvent, et j’en suis moi même la preuve : lorsque j’ai décidé de passer sous GNU/Linux, c’était plus par curiosité – parce que cela était amusant – que parce qu’il s’agissait d’une solution fonctionnant grâce et pour le logiciel libre. Ce n’est qu’au fur et à mesure de mes pérégrinations que j’ai cherché à approfondir cette question qui me semble désormais essentielle.

Cela semble pourtant être une évidence : « J’utilise Linux, donc je sais de quoi il retourne ». Malheureusement, c’est assez souvent faux ! Parce qu’il est nécessaire d’avoir une démarche personnelle vers le Logiciel libre pour en comprendre la grandeur, et pour saisir les messages d’ordre philosophique et politique (au sens noble du terme) qu’il engage¹.

On compare trop souvent GNU/Linux à Windows, et c’est un tord: L’un n’est pas l’autre², et les principes qui les régissent, même si ils suivent les même bases techniques (ce sont tous deux des systèmes d’exploitation voués aux mêmes finalités), sont complètement différents voir parfaitement opposés: l’un défends le logiciel libre tandis que l’autre s’inscrit dans une logique de profit économique, et de « programmation égoïste »³.
Ce sont ces principes et cette idéologie, qui ont permis à GNU/Linux de devenir ce qu’il est. Cela à fonctionné parce qu’il s’agit d’un logiciel libre, permettant à chacun, à son échelle, de participer au projet comme il l’entends.

Il semble donc primordial de ne pas reléguer le logiciel libre à un simple contexte de développement, ayant permis de donner naissance au paysage libre actuel. C’est ce qui semble se passer, et la conséquence est simple: les contributions ne sont pas à hauteur du succès des différents projets⁴.

Le simple fait d’utiliser des logiciels libres ne suffit pas à contribuer à son évolution, il est nécessaire de s’y impliquer pour que cela fonctionne⁵. La déclaration d’un bug ou un simple retour utilisateur permettent alors de contribuer, à votre échelle.

Avec GNU/Linux, vous avez le pouvoir de faire évoluer les choses, utilisez le !

1. le projet GNU est une ressource intarissable à ce sujet
2. Lire l’excellent article de Sébastien Sauvage à ce sujet
3. au sens ou l’entends Gerald Weinberg dans son ouvrage The Psychology of Computer Programming
4. ça en fait d’ailleurs râler certains
5. C’est d’ailleurs ce point qui est à l’origine des désaccords entre les partisans du Logiciel Libre et ceux de l’Open Source…

Rien de bien sorcier, mais les albums en question étaient fournis sous le forme d’un seul et unique fichier, ainsi que d’un fichier .cue, contenant les informations de découpage des titres du dit album.

J’ai donc utilisé mp3splt, ainsi que flac2mp3.

Téléchargez les différents logiciels, installez les puis placez vous dans le répertoire contenant vos fichiers .flac et tapez:

Et en trois coups de cuillère à pot, le tour est joué!

Il est également possible de procéder de la même manière en obtenant un fichier ogg Vorbis, en utilisant oggconvert ou flac2ogg.

Il semble s’agir d’un problème de configuration, puisque, après création d’un nouveau compte utilisateur, la connexion en wifi au même point d’accès ce passe sans encombres.

un

me retourne une liste des fichiers potentiellement incriminés. Les fichiers de configuration concernant le wifi sont situés dans ~/.gconf/system/networking/wireless/networks.

Supprimez les dossiers portant le nom du SSID de votre connexion wifi, et relancez une session: Ils seront regénérés automatiquement à la saisie de votre clé de chiffrement.

Voici la ligne de commande permettant de supprimer l’intégralité de votre configuration :

Par contre, je n’ai aucune idée de la provenance du problème …