Depuis ce week-end, la communauté francophone du framework Django a enfin son site. Tout cela grâce au travail des contributeurs. Pour le moment se trouvent présents sur le site un guide d’installation du framework ainsi qu’un tutoriel qui permet de faire ses premiers pas dans le fabuleux monde de Django.

Se tiendra ce week-end, le 2 et 3 juin, à la Cité des Sciences à Paris la première journée python francophone organisée par l’afpy. On y retrouvera entre autres une présentation sur le framework Django réalisée par David Larlet.
De nombreux autres sujets seront proposés : Zope, Twisted, Python et la 3D, etc…
Le programme complet du week-end.

Un petit billet pour signaler l’ouverture de Prizee Labs. Un blog principalement orienté sur la technologie Flash et de tout ce qui l’entoure. On retrouve notamment des interventions de Francis Bourre le créateur de Pixlib une librairie bien connue dans le milieu Flash tout comme Kairos une extension de Pixlib développée par Cédric Nehemie.

Aujourd’hui je vais tenter de vous expliquer comment fonctionne l’un des Design Patterns les plus utilisé qui fut initialement proposé par le GOF (Gang Of Four) : le Design Pattern Stratégie.

Pour commencer, il peut être intéressant de rappeler ce que sont les Design Pattern ou “Motifs de conception” en français. Les Design Patterns sont un ensemble de solutions standards permettant de répondre à des problèmes de conception rencontrés lors du développement de projets orientés objet. Les Design Patterns se regroupent dans trois grands groupes : Créationnel, Structurel et Comportemental. Le motif de conception que l’on va voir aujourd’hui fait partie du dernier groupe : les comportementaux.

Le Design Pattern Stratégie

Description :

L’intérêt principal de ce motif de conception est de permettre l’encapsulation d’algorithmes et de les rendre permutables. En effet, imaginons que l’on souhaite changer dynamiquement le comportement d’un objet et cela sans modifier la classe de ce dernier. A première vue, celà semble plutôt compliqué… mais il n’en est rien
Prenons un exemple simple : Une classe Personne qui a le dont de se déplacer. On peut imaginer plusieurs types de déplacements : marcher, courir !
De manière générale on aurait tendance à créer une méthode par déplacement :

Exemple en Python:

class Personne:
def marcher(self):
print "je marche"

def courir(self):
print "je cours"

Exemple en PHP 5 :

class Personne
{
public function marcher()
{
print "je marche";
}

public function courir()
{
print "je cours";
}
}

C’est pas mal, mais rien de très dynamique ! En effet, imaginons que l’on souhaite ajouter un nouveau comportement de déplacement (par exemple : nager) il faudra ajouter une nouvelle méthode.
Stratégie va permettre à notre classe Personne de posséder un comportement de déplacement dynamiquement interchangeable. Pour cela nous devons externaliser les comportements de la classe en utilisant un système bien connu en POO : la composition.
Regardons le diagramme de classe suivant :

Le diagramme UML :

Ce schéma mérite une petite explication. Comme on peut le voir, la classe Personne ne possède plus les trois méthodes “marcher“, “courir” mais elles ont été remplacées par deux autres : “setMouvement” et “déplacer“. La première va nous permettre d’attribuer aux instances de la classe Personne un objet Mouvement. La seconde quant à elle va exécuter le mouvement précédemment attribué à l’objet Personne. Les comportements sont désormais des classes à part entière qui implémente l’interface Mouvement.

Exemple en python :

class Personne:
def __init__(self):
self.__mouvement = None

def setMouvement(self, mouvement):
self.__mouvement = mouvement

def deplacer(self):
if self.__mouvement:
self.__mouvement.execute()

class Mouvement:
def execute(self):
raise "Doit être implementé"

class Marcher(Mouvement):
def execute(self):
print "je marche"

class Courir(Mouvement):
def execute(self):
print "je cours"

pers = Personne()

unMouvement = Marcher()
pers.setMouvement( unMouvement )
pers.deplacer() #affiche "je marche"

unMouvement = Courir()
pers.setMouvement( unMouvement )
pers.deplacer() #affiche "je cours"

En Python la notion d’interface comme en Java ou PHP 5 n’existe pas. J’ai donc fait en sorte, dans mon exemple, que la méthode execute de la classe Mouvement soit obligatoirement redéfinie dans les classes qui étendent de celle-ci.

Exemple en PHP 5 :

interface Mouvement
{
public function execute();
}

class Marcher implements Mouvement
{
public function execute()
{
print "je marche";
}
}

class Courir implements Mouvement
{
public function execute()
{
print "je cours";
}
}

class Personne
{
private $mouvement;

public function setMouvement( Mouvement $mouvement )
{
$this->mouvement = $mouvement;
}

public function deplacer()
{
if( !is_null($this->mouvement) )
{
$this->mouvement->execute();
}
}
}

$pers = new Personne();

$unMouvement = new Marcher();
$pers->setMouvement( $unMouvement );
$pers->deplacer();// affiche "je marche"

$unMouvement = new Courir();
$pers->setMouvement( $unMouvement );
$pers->deplacer();// affiche "je cours"

La méthode deplacer appelle la méthode execute du mouvement passé en paramètre. On s’aperçoit dans cet exemple que comportement de la méthode deplacer est modifiable dynamiquement. Lors de son premier appel elle affiche “je marche” puis “je cours” lors du second appel. Ceci est du au fait que le mouvement passé en paramètre n’est plus le même. Imaginons désormais que l’on doivent ajouter un nouveau comportement de déplacement (par exemple : “nager”), il suffira tout simplement de créer une nouvelle classe nommée Nager qui implémente la classe Mouvement.

class Nager(Mouvement):
def execute(self):
print "je nage"

pers = Personne()

unMouvement = Nager()
pers.setMouvement( unMouvement )
pers.deplacer() #affiche "je nage"

Très pratique si votre boss ne vous à fourni que la version compilée de la classe Personne On peut modifier son comportement sans toucher une seule ligne de celle-ci.

Et voilà que ce premier tutoriel sur les Design Patterns touche à sa fin. En espérant que ça vous a plu…

Depuis peu je suis passé sous la dernière version de Kubuntu : la Festy Fawn. Mais un petit bug semble être apparu. En effet, lors de l’ouverture d’une seconde console dans Konsole ou Yakuake, celle-ci n’est pas transparente malgré la configuration qui normalement le permet.

Après quelques recherches, il semblerait que celà soit un soft nommé ‘Scim’ qui poserait problème. Donc pour rétablir cette fameuse transparence, il suffit tout simplement de désinstaller tous les packages scim (pour ma part : libscim8c2a, libskim0, skim, et scim-qtimm)

Relancer Konsole et/ou Yakuake et le tour est joué!

Pour ceux que ça intéresse voici un petit lien qui explique à quoi sert SCIM

Depuis quelques temps, une guerre de la recherche sur internet est à l’oeuvre. Elle oppose bien entendu les deux géants de l’informatique Google et Microsoft. D’après un article publié sur linuxfr.org, il semblerait que le géant de Redmond aurait mis en place une nouvelle stratégie pour contrer l’enseigne au grand G. Celle-ci se résumerait à payer de grandes entreprises afin qu’elles bloquent l’utilisation des moteurs de recherche concurrents à leurs employés. Microsoft créditerait ainsi l’entreprise pour chaque recherche effectuée sur son moteur.
Ce nouveau procédé semble démontrer que Microsoft est totalement désemparé face à la concurrence, se voyant réduit à payer ses propres clients afin de les incités à utiliser l’un de ses produits phare présent sur la toile.

Aujourd’hui nous allons voir un petit test de performance sur des appels de fonctions récursifs grâce à la suite de Fibonacci dans deux langages distincts : le PHP et le Python.
Ce test a été réalisé sur la machine suivante :
Intel P4 3.2 Ghz, 1Go de Ram et accompagné d’une distribution Gnu/Linux Ubuntu Edgy Eft.

Version de Python : 2.4.4
Version de PHP : 5.1.6

Voici donc la version du script en PHP nommé test.php :

function test( $n )
{
if( $n <= 1 )return $n;
return test( $n - 1 ) + test( $n - 2 );
}
test( 35 );

et voici la version Python nommé test.py :

def test( n ):
if n <= 1:
return n
return test( n - 1 ) + test( n - 2 )
if __name__ == "__main__":
test( 35 )

Maintenant que nous avons réalisé les deux scripts, il ne reste plus qu’à les exécuter. Pour cela nous allons utiliser un petit utilitaire fort sympathique (time) afin de connaître le temps d’exécution de chacun d’entre eux.

Voici donc le lancement du script PHP:

$ time php test.php

Les résultats que j’ai pu obtenir sur ma machine :

real    0m26.236s
user    0m25.846s
sys     0m0.012s

Voici donc le lancement du script Python:

$ time python test.py

Les résultats que j’ai pu obtenir sur ma machine :

real    0m15.110s
user    0m15.077s
sys     0m0.004s

Il semblerait donc que Python soit réellement plus performant sur ce type d’opération, mais bien sur on ne peut pas choisir un langage uniquement sur ce type comparatif. Néanmoins, il peut être intéressant de connaître les performances d’un langage avant de faire son choix.

Pour toutes les personnes utilisant la technologie Flash, AMF PHP est souvent une réponse adéquate pour répondre à un nombre important de problèmes rencontrés lors du développement d’applications de type Flash Remoting.

Cette technologie séduisante pour le commun des flasheurs peut rebuter un passage de PHP à Django coté serveur.
Ce manque n’existe plus ! En effet, j’ai pu tomber par hasard sur le site DjangoAMF qui nous propose donc un middleware Django nous permettant d’utiliser le Flash Remoting. Ce plugin semble tout jeune (version 0.3.2) mais néanmoins actif (dernière mise à jour faite le 19 janvier 2007 )
Il semblerait qu’il soit développé par une équipe japonaise, mais fort heureusement une documentation anglaise est présente sur le site.
Je n’ai malheureusement pas encore eu le temps de tester tout cela, en espérant le faire dès que possible…

Voici une petite découverte trouvée sur le site Google Video. C’est une conférence google sur le thème du Framework Django, réalisée par Jacob Kaplan-Moss le 26 avril 2006. Ce dernier, qui est l’un des co-fondateurs du projet Django, nous présente les grands points forts du Framework.
Cette vidéo dure 1h 14 min et elle est en VO.

Je vous propose aujourd’hui un mémento réunissant les différentes commandes du framework Django, les tags de templates, les modèles…
Ce document est disponible au format PDF sous licence Creative Commons AttributionNonCommercialShareAlike. Ce n’est que la version 0.1 du document. De nombreux ajouts et modifications sont à venir. A vos propositions

Edit : Mise à jour 0.1.1 du mémento (correction du lien vers django-fr.org et modification de la couleur de fond)

Télécharger le mémento Django au format PDF :

Mémento Framework Django Version 0.1.1