Django Python and the meaning of Scrum

J’ai pu assister ce vendredi à une conférence organisée par le réseau Particul.es concernant Scrum, Python & Django. Ayant pas mal touché à Django y’a quelques années (4 ou 5) ; ayant été un grand fan de Python (le language et aussi les Monty puisque j’avais réalisé mon master sur le gang anglais, si si…), enfin étant aujourd’hui un défenseur ardent des méthodes agiles et plus particulièrement de Scrum j’ai immédiatement sauté sur l’occasion.

La conférence était organisée sur une alternance des “prez” 30mn sur un domaine, 30 mn sur l’autre durant 4h, saupoudrez de 30mn de pause.  Claude Aubry menait les affaires concernant Scrum, et David Larlet prenait en main les choses Python. Comme je vous le disais venant des deux mondes je me suis senti “dans le bain”, mais je m’interroge sur les personnes n’étant venu que pour un seul domaine. D’un côté cette alternance donnait du rythme mais d’un autre elle a peut-être empêché de creuser assez un sujet, ou d’interroger assez précisément un intervenant : pas assez de temps libre “off” avec les intervenants ! ,  une déception je n’ai pas eu le temps de parler rock’n roll avec Claude Aubry entre autres.

Pour résumer, c’était très agréable de replonger dans le bain django/python, et cela semble être comme le vélo : on n’oublie pas. Mais je reste encore dubitatif sur la percé du langage dans les entreprises ne serait-ce qu’en raison de la rareté des compétences locales.  Quand à Scrum rien de nouveau de mon côté, mais ce fut un plaisir de croiser et d’entendre cette présentation par Claude Aubry (il faut que je m’achète un chrono de cuisine pour mes timeboxes). J’ajoute : très beaux slides de David Larlet : simple et évocateur (des planches creative commons de flickr), une bonne idée que je vais reprendre (mais n’est-il pas developpeur web ? )

Enfin, première rencontre avec les gens de Particul.es. Sympa ! A ce sujet, ces deux conférences en une sont le prélude de formations/coaching autour de ces deux domaines (Python/Django & Scrum). Je vous encourage à aller sur le site pour en savoir plus (http://particul.es).

[ajout] Réflexion dans le bain cet après-midi : le vrai point commun entre Scrum & Python c’est le fait qu’ils sont tous les deux compacts. On s’approprie facilement et aisément les règles, librairies, de ces deux outils. inutile d’aller fouiller dans une documentation pour consulter le point x-44-b (comme Java par exemple qui se noie sous la documentation, ou CMMi…). L’outillage est là, présent, facile à appréhender, à l’esprit : c’est productif.

This entry was written by pablo, posted on October 25, 2009 at 7:32 am, filed under méthodes agiles, opensource, python, scrum, technologies and tagged django, monty python, particules, python, scrum. Leave a comment or view the discussion at the permalink.

La fièvre (jaune) du post it

Post It F(or)ever

Une des phrases qui m’avait le plus intriguée à la première lecture du célèbre Scrum & Xp From the Trenches était celle concernant les fichiers excel : oubliez, arrêtez de les employer, ça pue. Personne ne les utilise, personne ne les lit. Appartenant -toujours- en ce moment à une société avec une grosse culture CMMi, lire ça c’est un peu comme lire un roman érotique au milieu d’une abbaye, une révélation autant qu’un parjure.

Mais les faits sont là. Les radiateurs (gros tableaux faussement bordéliquessur lequels on déploie les postits) Scrum possèdent d’énormes bénéfices. Visibilité : au sein de l’équipe, mais aussi beaucoup auprès des autres : sur quoi l’équipe travaille, à quel rythme, qu’est ce qu’elle a déjà réalisé, etc. Usabilité : C’est étonnamment pratique ce petit bout de papier jaune : facile à accrocher, facile à déplacer, à la bonne taille pour nous obliger à aller à l’essentiel dans nos descriptions.Si on écrit trop dessus, c’est le signe qu’il en faut plusieurs et pas un. Si on a des agrégats trop importants c’est le signe qu’il faut les déployer, disperser, repenser. Autre instrument essentiel : l’appareil photo. Il permet d’historiser le projet.  Je me rappelle un top level high board manager m’ayant glissé : c’est bien tout cela mais a) tu me fais des trous dans le mur et ça va nous coûter cher en cloison si on déménage (je suis passé au scotch), b) comment je fais pour accéder à l’historique de la consommation de charge du projet ? (d’où les photos).

Le post-it n’est d’ailleurs vraiment pas l’apanage des projets Agiles. Ses propriétés (concis, agrégation visible, souplesse d’utilisation) sont exploitées dans de nombreux cas. Les Web agencies par exemple… et le tri sur cartes. Même causes, même effets : on découpe une arborescence, un rubriquage par fonction, par contenu, on opère des regroupements logiques. Les gros” pavés”, les déséquilibres émergent. On organise aisément, visuellement, les ensembles, les sous-ensembles. L’équilibre est visuel.

Voilà pour ce petit post (it). J’y retrouve aussi un pied de nez très plaisant à tout cet outillage dispendieux et pléthorique derrière lequel on cherche trop souvent à se cacher. Mais surtout, surtout, ça marche. c’est efficace. c’est productif.

This entry was written by pablo, posted on October 14, 2009 at 12:33 pm, filed under méthodes agiles, scrum and tagged cmmi, postit, scrum. Leave a comment or view the discussion at the permalink.

Elgg, REST API

Petit retour sur Elgg. A l’occasion d’une petite (mini) mission je me suis penché sur l’API REST. L’objectif étant de brancher Elgg et son moteur (engine/lib) en utilisant son API REST à un service WS Soap tiers pour l’alimenter. En quelques mots : brouillon mais prometteur.

Pour rentrer plus précisément sur le sujet je devais générer des groupes dynamiquement en puisant les infos dans un WebService SOAP externe. Ce que mon proto met en avant : il est tout à fait possible d’”exposer” (selon la terminologie elgg) toutes les fonctions liées aux entités de Elgg. C’est à dire que l’on rend accessible via une API REST les fonctionnalités des briques de Elgg. Pour cela il faut créer un plugin (du moins je m’y suis pris ainsi). Créer un plugin c’est deux coups de cuillère à pot :  un fichier manifest.xml qui dit qui/licence/version, un fichier start.php qui permet de générer ses fonctions et surtout de les enregister au sein du fonctionnement de Elgg. Je n’ai pas creusé l’aspect MVC du produit mais après si je regarde les autres plugins tout semble couler assez de source : dossier view, dossier action, etc. Le fait de manipuler les librairies Elgg depuis son infrastructure rend tout plus simple : on accède à toutes les librairies tous les objets/entités, toutes les fonctions. Y’a plus qu’à.

Il ressort cependant que l’API n’est pas très propre au niveau du codage et que pas mal de petits bugs sont présents.J’adore à ce sujet le passage du wiki :

Note: Elgg’s REST API has many bugs so developers need to beware that development with it will take longer than expected as you run up against these bugs

Par exemple dans mon code, j’ai eu besoin de faire un accès direct  à la base de données (ce qui n’est pas vraiment conseillé…) l’API de l’entité “group” ne fonctionnant pas pour l’attribut owner_guid. Enfin j’ai aussi par exemple supprimé des validations de paramètres dans l’API REST qui fonctionnaient de manières incohérentes. Enfin si il semble dans la documentation que les questions de sécurité soient bien prises en charge, j’ai eu la surprise de noter que suite à mon installation on pouvait déclencher la fonctionnalité sans aucune restriction via un url / méthode GET (alors que j’avais préparé un script mettant en place des headers/entêtes http spécifiques pour palier à cette question d’authentification). Alors soit c’est un leurre (la sécurité de l’API). Soit j’ai raté un épisode et j’ai pas compris ou activé la sécurisation de l’API (la bonne hypothèse probablement). A fouiller donc.

Ces divers désagréments ne sont cependant pas bloquants. Elgg et son “engine” et API REST sont très prometteurs. Le code va aller en s’améliorant, il est déjà correct. Les questions de sécurité peuvent être traitées à un autre niveau : sécurisation des urls REST via Apache par exemple.

Pour tout cela il s’agit de développement php/mysql relativement classique, donc efficace et productif. Il faut cependant mettre un bémol sur cette productivité en raison de la jeunesse de la plate-forme Elgg et des anomalies qu’on y trouve toujours encore régulièrement.

quelques urls intéressants :
des exemples de codes et infos concernant l’API :
http://trac.elgg.org/elgg/browser/trunk/mod/apitest/start.php?rev=430
http://www.danielansari.com/wordpress/2008/12/how-to-use-the-rest-api-in-elgg-11/

Quelques bouts de code :

le plugin :fichier start.php

<?php

function haras_init()
 {
 /** j'expose ma fonction  au travers de l'api REST */
 expose_function(
 'group.create', //method
 'createGroup', //function
 array (
  "user_guid" => array('type'=>'string'),
 "montrucnumber" => array('type'=>'string')
   ), // parameters
 elgg_echo('group.create'),  // description
 "GET", // call_method
 false, // auth token
 true // anonymous   <-- sûrement cette ligne mes questions sur l'authentification   
  );
  }

function getMontruc($montruc)
 {

  /** je récupère l'objet vers le service SOAP tiers */

}

function createGroup($user_guid, $numtruc)
 {

[...]

 $montruc = getMontruc($numtruc)

/** je crée dynamiquement un groupe */

 $group = new ElggGroup();

 $user = get_entity((int)$user_guid);

 $group->name = $montruc->name;
 $group->description = $description;
 $group->access_id = 2;
 $group->membership = ACCESS_PUBLIC;
 $group->files_enable = get_input('files_enable', 'yes');
 $group->pages_enable = get_input('pages_enable', 'yes');
 $group->forum_enable = get_input('forum_enable', 'yes');

 $group->save();

 $group->join($user); // toujours créer un utilisateur après la création du groupe

 /** l'API ne fonctionne pas je dois manipuler
 // sale mais nécessaire, api bugguée
 $dblink = get_db_link('write');
 $query = "update elggentities set owner_guid =" . $user_guid . " where guid=" . $group->guid;
 $result = execute_query("$query", $dblink); 

 return 'group ' . $group->name . ' ' . $group->owner_guid . ' created';  // ouh là là le proto
 }

/** très important, on enregistre le service/handler auprès de Elgg */
 register_elgg_event_handler('init','system','haras_init');

?>

This entry was written by pablo, posted on October 8, 2009 at 2:57 pm, filed under php, technologies and tagged api, elgg, mysql, php, rest. Leave a comment or view the discussion at the permalink.

mon “PHP TREE Map Opensource”

Les choses ont bien changées depuis une dizaine d’années. PHP n’était pas vraiment ma tasse de thé à la fin du siècle précédent. Une auberge espagnole, un bazar sans nom, qui ne donnait pas confiance. On y trouvait de tout mais aussi beaucoup de n’importe quoi. Mais les choses ont bien changées. Il me semble que PHP est arrivé à l’âge adulte aux alentours de 2004, 2005. Aujourd’hui j’esquisse un sourire quand je vois certains de ces développeurs Java, C# ou autre, qui se gaussent de ce language du peuple, se faire complètement dépasser par son succès. Car aujourd’hui PHP est fiable, puissant, et il est la source de nombreux logiciels phares des entreprises modernes. Il accompagne l’émancipation de l’opensource, et son spectre d’action s’étend de plus en plus à des logiciels métiers à forte valeur ajoutée. Il reste encore une terra incognita au main de Java ou autres, mais peu à peu son rayon d’action en fait une technologie incontournable dont la prise en main est aisée et la productivité garantie (si l’on ne cherche pas à réinventer la roue). Même des grandes comptes assez inattendus (comme dans le milieu banquaire par exemple) ont franchi le pas. J’attends donc avec impatience que les Liferay, Alfresco, Pentaho, OpenBravo et consort trouvent leur alter ego php.

Ps : ci-joint un arbre des solutions PHP que je viens de réaliser, un dessin valant mieux qu’un long discours.

Si vous souhaitez m’éclairer sur une solution opensource, fiable, php, qui complète ce diagramme je suis preneur !

This entry was written by pablo, posted on October 5, 2009 at 6:36 pm, filed under opensource, php, technologies and tagged java, opensource, php, tree. Leave a comment or view the discussion at the permalink.