Carte heuristique : projets d’enterprise search

23 Dec 2009 at 16:20

pablo

gestion des connaissances (km), moteur de recherche

No Comments

J’ai réalisé -rapidement, elle n’est donc pas exhaustive- une petite carte heuristique pour mettre à plat les enjeux et objectifs d’un projet d’enterprise search. (pour la carte j’ai utilisé VYM, cliquez sur l’image pour la récupérer en grande taille).

Il s’agit d’une avant-vente afin de ne pas me faire abuser par la concurrence et aussi de certifier qu’il s’agit bien de l’un de mes documents j’ai grossièrement ajouté mon nom en fond (c’est du creative commons à l’arrache…). Si quelqu’un cherche le diagramme sans cette dégradation qu’il me fasse signe, aucun souci.

Leaders & managers, Scrum & Cmmi, billet #2

20 Dec 2009 at 13:52

pablo

XP, cmmi, méthodes agiles, scrum

4 Comments

J’entame donc ces petites mises en perspectives entre Scrum et CMMi par les questions de management de projet. Je ne vais pas mettre -encore une fois- en avant la dichotomie entre le chef de projet et le scrummaster, elle ne m’intéresse pas forcément telle qu’elle est présentée et elle n’est pas forcément aussi vraie que cela. Non pour juste dire ce qui sépare dans ma pratique de Scrum et de CMMi la notion de chef de projet/scrummaster je vais plutôt m’appuyer sur un passage de l’excellentissime “Lean Software Management” de Marie et Tom Poppendieck (que j’encourage tout le monde à lire) qui lui même cite le livre “What leaders really do” de John Kotter. Synthétiquement on va séparer deux profils : les managers et les leaders.

Du côté du manager : on planifie, on budgetise, on organise, on “staff”, on trace et on contrôle. Du côté du leader on indique la direction, la vision, on fédère les gens, on motive les équipes.Voilà tout est dit. Oui je sais j’enfonce allègrement des portes ouvertes.

1ère porte ouverte enfoncée : Rien n’empêche à un chef de projet CMMi d’indiquer la direction la vision, de fédérer les gens, etc.. au contraire c’est la panacée. L’inverse pour le scrummaster est aussi vrai. Seulement il faut bien garder en tête que l’on va d’abord demander à un chef de projet CMMi d’organiser de tracer et de contrôler, et que l’on va d’abord demander à un scrummaster de fédérer et d’accompagner l’équipe.

2ème porte ouverte enfoncée : Certaines personnes ne seront jamais compatibles avec l’une de ces deux missions, ce n’est pas dans leurs natures, cela ne les intéressent pas. J’insiste surtout les notions de fédération de motivation, de leadership, et là je sors un joker un peu tarte à la crême : tout cela est aussi beaucoup affaire d’empathie et de psychologie.

Quelques paradoxes aussi :

Le management désire des leaders, cela donne de la cohésion à ses équipes, cela génère des dynamiques, et ils sont généralement des différentiateurs forts dans les appels d’offres. Car le leader possède une compétence (souvent technique) forte. C’est souvent là dessus qu’il assied son leadership. Oui à mes yeux un ScrumMaster doit avoir une compétence technique conséquente, ce qui n’est absolument pas un pré-requis pour le Chef de projet (CMMi). Au contraire souvent je vois pas mal de gens désirer le poste de Chef de projet pour s’extraire des contingences techniques : ils ne souhaitent plus développer. Ils veulent prendre “de la hauteur” (faire les spécifications, tracer, contrôler, etc.). C’est la verticalité des rôles CMMi. Verticalité exprimée aussi par la hiérarchisation : le Chef de projet est chapeauté par de le Directeur de projet. A l’inverse je perçois le modèle Scrum comme horizontal. Le Scrummaster, le Product Owner, l’Equipe, tout le monde est sur le même plan. Je reviens à mon propos : le management désire des leaders pour tout les raisons évoquées plus haut. Mais cela l’embête bien. Pour lui c’est plus simple de ne pas valoriser certaines personnes, c’est plus simple d’interchanger les personnes, de consolider et de prévoir si il n’y a pas de disparité dans les profils. C’est un reproche assez fort que je fais à l’implémentation de CMMi tel que je l’ai vécue : une hypocrisie forte à continuer à présenter les gens comme égaux, ou tout au moins “assez armé” (grâce aux processus mises en oeuvre pour répondre au modèle CMMi), pour pouvoir être placés, déplacés, interchangeables. J’exagère un peu, mais c’était l’idée dominante dans mon vécu. Dans les faits, tout le monde savait exactement que c’est le contraire qui était vrai. Le management veut des leaders mais préfère gérer des “managers”. En fait là j’étend la notion de leader à celle de personne clef. C’est différent, mais dans les relations que j’ai perçu entre management et équipe, avec scrum ou cmmi, la réponse était la même. Cela dérange CMMi d’avoir des personnes clefs car justement le modèle refuse une trop forte personnalisation et se base sur de fortes pratiques. Or tout le monde sait qu’un projet se bâtit sur des personnes clefs. Dernière remarque à ce sujet, une personne clef un jour ne l’est pas nécessairement le lendemain. Je veux dire par là que ce n’est pas une façon de distinguer des bons et des mauvais, pas du tout.

La verticalité que j’évoque dans le modèle classique CMMI et du chef de projet, a le mérite de proposer une hiérarchie claire : chef de projet, directeur de projets, voire top management, et puis les -plus bas- les développeurs, transverse, les responsables qualité, etc. Il est clair que pour les développeurs ce n’est pas valorisant. Mais c’est assez reposant (moins de responsabilité et d’implication). C’est la hiérarchie qui va encaisser les chocs (quand elle joue correctement le jeu, et que le Chef de projet n’est pas un fusible). Elle a les moyens de substituer le chef de projet (ou une autre personne) si quelque chose coince (pour x raison, ne serait-ce au bout d’un certains que l’usure…). Chez Scrum c’est plus compliqué, le système est normalement comme je le dis, horizontal. Ce n’est pas simple. Si un membre de l’équipe ne fait pas l’affaire ? (“on le sort au plus tôt !” nous dit Extrême Programming, “tu lui en as parlé et qu’en pense-t-il” nous dit scrum, dans les deux cas de jolies phrases mais peu réalistes).Pas d’échappatoire, beaucoup moins de leviers sur lesquels jouer. La mayonnaise prend, …ou pas, il n’y a pas de prédictibilité. Un projet Scrum ou la mayonnaise ne prend pas, c’est complexe, que faire sinon faire le constat de l’échec et : changer les équipes (!!!), passer dans un autre mode ? Mais au moins on aura rapidement de la visibilité sur ce problème.

Ce rôle de ScrumMaster que j’associe au leader est d’autant plus complexe que ce leader doit s’effacer pour que l’équipe et le product owner prennent leur responsabilité.

Donc,

Le chef de projet de CMMi est d’abord pour présent pour consolider toutes les infos, traces, planning, etc. du projet. Si quelque chose va de travers il est sensé anticiper et alerter ou déclencher des actions pour palier aux risques présents ou aux problèmes qui apparaissent. Il surveille : le périmètre, les livrables, les compteurs, les équipes, etc. Il rend compte à sa hiérarchie. Il lutte souvent -presque au corps à corps :p – avec le client pour protéger le cadre très strict de son contrat. Il s’assure d’ailleurs de la fiabilité de son contrat et que son plan d’action et de moyen est clairement défini et applicable. “Le projet sera délivré en temps et en heure avec toutes les fonctionnalités définies dans les spécifications”, c’est son mojo. A la limite si les développeurs et le client le haïssent cela simplifie les relations.

Le ScrumMaster est d’abord présent pour consolider l’équipe autour de la valeur à générer : les users stories, les fonctionnalités à développer, le vrai besoin du client. Si quelque chose va de travers il doit s’en occuper ou trouver au sein de l’équipe ou du côté du product owner une solution. Il s’assure que c’est d’abord de la valeur que l’on produit. Il collabore avec le product owner et l’équipe et les accompagne quand ils rendent compte au client (au travers des retrospectives). Il doit aussi planifier les release et les sprint à venir. Quand son manager lui demande comment il consolide les données du projet : il lui répond qu’il n’a qu’à observer les photos des radiateurs (post-it sur le murs) et se prend une soufflante. “Oui nous n’avons pas couvert tout le périmètre mais ce que nous avons délivré est exploitable, de très bonne qualité, et vous amène beaucoup de valeur ; pour vous le rapport qualité/prix est excellent”, c’est son mojo. Si les développeurs forment une équipe soudée qu’il a su motiver autour des besoins du client il sait que le projet va réussir.

Scrum et CMMi, billet #1

08 Dec 2009 at 14:06

pablo

cmmi, scrum

4 Comments

Je souhaite réaliser une petites séries de billets dont le but est une mise en perspective entre Scrum et CMMi. Ces billets n’ont pas pour but de préconiser l’un plutôt que l’autre mais de faire partager mon humble expérience à ce sujet : je viens de passer plus de 3 années au sein d’une structure dont CMMi a été l’épine dorsale. A ce titre et ayant œuvré en tant que consultant ou chef de projet j’ai mis en œuvre des pratiques CMMi jusqu’au niveau 4. J’ai abordé Scrum il y a 3 ans mais cela n’a pas été retenu alors dans cette structure, et seulement depuis fin 2008 les projets Scrum sont déroulés. La question revenant régulièrement sur le tapis, écrire des billets à ce sujet me permet aussi d’organiser ma pensée.

Naturellement la première chose que je vais entendre (ou lire) c’est : CMMi est un modèle et Scrum une méthode. On ne peut donc pas les comparer. Je rejette cet argument dans le sens où chaque société implémente CMMi “à sa guise”, et donc je compare l’implémentation de CMMi (telle que je l’ai connu) à l’implémentation de Scrum. Il est d’ailleurs assez amusant de constater que cette défense de CMMi vis à vis de Scrum prolifère récemment alors que l’implémentation de CMMi est -très- sérieusement bousculée par l’implémentation de Scrum.

Oui il y a une opposition philosophique entre ces deux méthodes, c’est pourquoi l’une bouscule l’autre à mon sens. Par contre il est évident que les deux peuvent dans bien cas se conforter.

Je dois dire qu’au sein de l’organisation dans laquelle j’ai déroulé les pratiques CMMi l’arrivée de Scrum est réellement vécue comme une bouffée d’air frais. Surtout en raison d’un monopole trop totalitaire de cette doctrine (CMMi). Je suppose que dans quelques années un monopole de Scrum pourra tout aussi bien être bousculé par une nouvelle approche.

Les points que j’espère aborder :

  • Pour le nouvel arrivant, le débutant, quels sont les bénéfices et inconvénients de CMMi et Scrum.
  • Les bénéfices et les risques CMMi & Scrum, je vais essayer de dire quand est-ce que je m’appuierai plutôt sur Scrum ou plutôt sur CMMi, et dans quels cas les deux peuvent cohabiter voire se renforcer.
  • d’autres peut-être !

J’espère ne pas me perdre, ni être trop ambitieux et surtout vous donner mes arguments de terrain (donc forcément il seront “teintés”).

Mais que manque-t-il à Java ?

02 Dec 2009 at 17:36

pablo

java

No Comments

Il faut éviter : d’avoir des discussions techniques/boulot lors des pauses déjeuners

Il faut éviter : d’avoir des discussions techniques/boulot avec une pression à la main

C’est pourtant le piège dans lequel une fois de plus nous avons chuté, Blazing Nick (c’est son surnom de catcheur, il ne veut pas que j’emploie son vrai nom pour ne pas exploser les stats de mon blog), et moi même. Nous avons donc parlé Java (je devais vouloir lui remonter le moral). Et notamment de la sortie de la version 7 qui semble être comme la marée, elle s’approche, elle s’éloigne. Java / MySQL, même combat, depuis le rachat de Sun par Oracle, tout le monde est sur l’expectative.

Bref nous avons donc parlé Java, futur, amélioration : avec Blazing Nick dans le rôle du gentil (le pro Java) et ma pomme dans le rôle du méchant car Java n’est pas nécessairement ma tasse de thé (en tant que langage, car les solutions métiers comme Liferay, Alfresco ou Lucène entre autres ont largement fait leurs preuves). Qu’est ce qui va donc arriver avec ce Java 7. Rien manifestement, en tous cas rien de bouleversant si j’en crois Blazing Nick. Et d’ailleurs de quoi a-t-il besoin ose-t-il me narguer ?

Amélioration des perfs ? non pas vraiment. Que l’on allège ce langage bien trop déclaratif, ces fichiers de conf bien trop alambiqués ? Ben non ce que nous aimons me dit Retorquing Nick. Un mode “script” ? Il existe si on veut l’utiliser. Alors quoi. On tergiverse, on lance des pistes, etc. (n’oubliez pas on a des pressions à la main). Finalement on se rejoint sur un point: Il faudrait faciliter le déploiement d’une appli Java en la déposant directement dans un dossier et que Apache puisse la lire sans trop poser de question. Qu’il ne soit pas nécessaire d’embarquer un conteneur de servlet genre Tomcat à brancher sur Apache (avec mod_jdk ou autre). Cela aurait pu exister depuis longtemps si la communauté java et la communauté opensource s’étaient trouvés plus d’atomes crochus, ce qui n’est pas vraiment le cas. Je fais mon dev, j’ouvre le navigateur, ça roule. Pas de processus trop lourd pour déployer lors du dev. Bref que l’adhérence entre le système et le moteur java soit invisible.

Pour le coup ce billet est vraiment une brêve de comptoir.

KanBan, Scrum, rythme et rituel

25 Nov 2009 at 10:27

pablo

kanban, méthodes agiles, scrum

No Comments

Ce billet prend naissance au travers de la lecture de cet excellent article : The philosophy of Kanban is Kryptonite to Scrum . Je n’ai pas mis en oeuvre KanBan. Je n’en ai pas eu à ce jour l’occasion (cela ne saurait tarder), mais prenez donc cet article avec des baguettes car je n’ai pas de feedback terrain à ce sujet.

Ma problématique :

  1. Scrum et les méthodes agiles connaissent un succès exponentiel en ce moment : il suffit de jeter un oeil au Google Trends…
  2. Les SSII veulent manger leur part du gâteau, les entreprises se ruent dessus
  3. Il n’est pas aisé pour les SSII ou les entreprises de mettre en place Scrum pour -à mes yeux- deux principales raisons : contractualisation, stabilité/pérénité de l’équipe (la troisième serait “responsabilisation” du product owner, et donc du client quel qu’il soit)

A la lecture de l’article cité ci-dessus je me dis que la solution réside peut être dans KanBan. Il ne règle pas la question de contractualisation mais il peut régler celle de la stabilité de l’équipe. Pourquoi ? Scrum apporte beaucoup de souplesse en réponse aux besoins d’un projet, mais il n’introduit pas nécessairement beaucoup de souplesse au sein de l’organisation. Il nécessite un rituel fort et contraignant : les sprints,  les daily scrum, les retrospectives, le tout organisé autour d’une équipe très stable et très impliquée. Pour une SSII (ou une entreprise) ce n’est pas si simple à mettre en oeuvre. Rare sont les moments où une équipe peut effectivement entièrement se consacrer à son sprint. Rare sont les projets ou une personne/évènement externe ne vient pas bousculer le planning, les priorités. KanBan propose un cadre moins rigide (oups scrum méthode agile serait rigide, non ne me faites pas dire cela), en tous cas il propose moins de recommandations d’une part (pour reprendre les termes de Henrik Kniberg (cf les liens ci-dessous)), et ne l’assujetti pas à des timeboxes et un rituel régulier (stand up, etc..). Mais le cycle de Kanban se différencie de la vélocité de Scrum. Le rythme/”flow” de Kanban me parait beaucoup moins contraignant. la vélocité de Scrum est rythmée par le rituel, mise en exergue par les burndown chart, on se doit de respecter l’itération : si une user storie n’est pas achevée à la fin du sprint elle n’apparaitra pas dans la démo, elle a été hors du rythme et donc exclue. Là où Kanban -il me semble- va être plus docile : on déduit le rythme des faits, on ne s’y soumet pas.

Bref, l’exercice de suivre la rythmique de Scrum n’est pas aisé, je me répète, d’où aussi l’importance de la sensibilisation du management au respect des règles d’un projet Scrum. Mon propos est aussi de dire que des fois ce n’est pas possible et qu’il s’agit peut-être là finalement de plutôt se tourner vers Kanban (sans opposer les deux, ce en quoi je ne fais que redire ce que l’article cité ci-dessus explique bien mieux).

Autre point qui m’amène à évoquer KanBan, il se peut (double conditionnel alto arrière..) que je sois amené à coacher des équipes composées de 1 à 2 personnes dans un prochain temps. Avec 1 personne Scrum perd de sa substance…  On se retrouve simplement dans le mode héro (oyez CMMi niveau 1…), en espérant que cet acteur solo a une bonne culture de la gestion d’un projet informatique, des outils qu’il peut mettre en place, etc, mais nulle question à mes yeux de réaliser un daily stand up seul, surtout si une seconde personne vient de façon épisodique compléter l’équipe.

Là encore KanBan avec son approche -apparemment- plus simple, et beaucoup moins ritualisée, va peut-être pouvoir répondre à ce besoin. En introduisant un simple “radiateur” KanBan je peux amorcer une gestion rythmée du projet, je n’ai pas de sprint à respecter, je peux introduire une seconde personne de façon épisodique. Bref je me répète :  je peux rythmer plus simplement le projet  et qui dit rythme, dit charge et planification et donc indicateurs et prévisions, etc.

Pour finir et afin de le rappeler une nouvelle fois, je n’ai pas encore mis en oeuvre Kanban à l’inverse de Scrum, excusez moi par avance si j’avance ici des grossièretés à vos yeux de Kanbanmaster (?). Je veux simplement souligner pourquoi KanBan serait une piste intéressante. J’en décèle deux : impossibilité d’appliquer le rituel de Scrum et de garantir la stabilité de l’équipe, l’un étant souvent le corollaire de l’autre.

Un autre article très intéressant : Kanban and Scrum a practical guide et surtout le PDF associé qui compare Scrum à KanBan, celui avec la citation de Myamoto Musashi, …

Kanban and Scrum – a practical guide

Check CMMi et projet scrum

06 Nov 2009 at 08:47

pablo

cmmi, méthodes agiles, scrum

5 Comments

CMMi ?

Je viens de passer un “check CMMi” avec pour sujet un projet Scrum dont je suis le ScrumMaster. On lit beaucoup de choses sur les liaisons ou équivalences en CMMi et Scrum, par exemple dans une annexe du bouquin de Ken Schwaber (“Agile Project Management”). Notamment sur les pratiques couvertes par Scrum concernant CMMI. Je reste assez dubitatif sur cette volonté de rapprocher ces deux méthodes car je perçois pour l’instant que ce n’est fait que pour rassurer certains clients, ou pour bâtir un argumentaire commercial. Actuellement -dans la société pour laquelle je travaille encore durant deux mois- c’est assez caricatural : les scrumers moquent les cmmis et vice-verça. Je joue moi aussi beaucoup à cela. C’est de la détente, hein. Mais je suppose qu’une vraie analyse des pratiques CMMi (telles qu’elles sont mises en oeuvre ici) via le prisme de Scrum apporterait une vraie (contre)analyse et permettrait de faire évoluer le modèle. Et là aussi vice-verça.

Scrum ?

Bref en tous cas je viens de passer un “check” : on vérifie l’application des pratiques CMMi sur vos projets au sein de l’”agence”. Parmi les points forts sont remontés le projet Scrum, notamment sur la pratique PMC (en gros gestion de projet) : visibilité et implication des équipes (le radiateur, les stand-up meeting, etc.), mais aussi sur la pratique VER (vérification) : test d’intégration et d’acceptation par le client à chaque itération. Bref : L’auditeur CMMi est  probablement moins borné que moi et a observé avec intérêt les pratiques Scrum !

MariaDB un nouveau MySQL

04 Nov 2009 at 10:58

pablo

database, mysql

No Comments

MariaDB c’est le bébé de Monty Widenius : fondateur de MySQL. C’est aussi un fork 100% compatible de MySQL.

“MariaDB is a drop-in replacement of MySQL, with more features, less bugs and better performance”, peut-on lire dans le README du dossier MariaDB 5.1.38 que je viens d’extraire, rien que ça ! MariaDB est un fork officiel de MySQL par l’un de ses fondateurs.Les différences entre MariaDB et MySQL sont listées ici. MariaDB est entièrement compatible MySQL, d’ailleurs toutes la documentation d’installation de MySQL est compatible (pour dire le démon se lance avec libexec/mysqld…bref C’EST MySQL). Essayons ! Je télécharge les sources, je compile. je déploie, je copie ma conf mysql, je fais les changements qui vont bien, je lance le mysql_install_db…

/opt/mariadb5138$ sudo bin/mysql_install_db --defaults-file=/opt/mariadb5138/my.cnf
Installing MariaDB/MySQL system tables...
OK [...]

Et je me retrouve avec :

/opt/mariadb5138$ sudo ls data/
maria_log.00000001  maria_log_control  mysql  test

J’ai toute une petite série d’exécutables MariaDB : maria_chk, maria_dump_log, maria_ftdump, maria_pack, maria_readlog : le moteur de stockage mariadb est sensé être crashproof, contrairement à MyISAM, et à l’instar de InnoDB. Bref je lance le biniou (c’est moi qui ai placé le démon sur le port 3308, et changé la socket).

/opt/mariadb5138$ sudo libexec/mysqld --defaults-file=/opt/mariadb5138/my.cnf --user=mysql
091103 16:23:22 [Note] Event Scheduler: Loaded 0 events
091103 16:23:22 [Note] libexec/mysqld: ready for connections.
Version: '5.1.38-maria-beta'  socket: '/tmp/mariadb.sock'  port: 3308  Source distribution

J’ai plus qu’à dumper mes données mysql vers mariadb(on va essayer une base eZ 4.2.0) (j’ai pris soin de placer comme moteur de stockage par défaut “maria”, sinon je vais devoir faire des alter table en pagaille)

mysqldump -u*** -p*** ez420 | mysql -u*** -p*** -S/tmp/mariadb.sock ez420

mysql> show table status like "ezcontentobject"\G
*************************** 1. row ***************************
 Name: ezcontentobject
 Engine: MARIA
 Version: 10
 Row_format: Page
 [...]

Ah je vois que j’ai un format Page (qui n’existe pas avec MyISAM).  Je note que l’on peut dans processlist analyser les temps des requêtes à la milliseconde prêt (ce que l’on peut faire avec MySQL Proxy, mais pas le mysql “de base”), je note que l’on a une analyse étendue des logs des “slow query”. Et pas mal d’améliorations côté performance. Je vois cela là.

Et je vois pas mal de variables associées au moteur de stockage :

mysql> show variables like "%maria%";
+-------------------------------------------+---------------------+
| Variable_name                             | Value               |
+-------------------------------------------+---------------------+
| maria_block_size                          | 8192                |
| maria_checkpoint_interval                 | 30                  |
| maria_force_start_after_recovery_failures | 0                   |
| maria_log_file_size                       | 1073741824          |
| maria_log_purge_type                      | immediate           |
| maria_max_sort_file_size                  | 9223372036853727232 |
| maria_page_checksum                       | ON                  |
| maria_pagecache_age_threshold             | 300                 |
| maria_pagecache_buffer_size               | 8384512             |
| maria_pagecache_division_limit            | 100                 |
| maria_recover                             | OFF                 |
| maria_repair_threads                      | 1                   |
| maria_sort_buffer_size                    | 8388608             |
| maria_stats_method                        | nulls_unequal       |
| maria_sync_log_dir                        | NEWFILE             |
| maria_used_for_temp_tables                | ON                  |
+-------------------------------------------+---------------------+

Si je fais un show create sur l’une de mes tables je vois ce paramètre (nouveau) : PAGE_CHECKSUM=1. Il me dit que cela accroit la sécurité autour de l’intégrité de mes données. Mais je dois aussi ajouter l’option TRANSACTIONAL pour rendre la table “crash safe” (rien à voir avec les transactions, en fait il journalise dans des logs). donc :

mysql> alter table ezcontentobject transactional=1;

Après tout cela mon site test ez420 fonctionne très bien. Le driver php_mysql continue à marcher as usual. Si j’essaye le module mysqli(mproved) ça marche aussi normalement. Bref je peux effectivement faire le remplacement tel quel de MyISAM par MariaDB (oui je sais des petits malins me diront que eZPublish nécessite un moteur InnoDB pour ses fonctionnalités transactionnels et ils auront raison. C’est juste un test sur la première base qui me tombe sous la main).

Tout ceci est très prometteur. Attention pour l’instant mariadb n’est pas un moteur transactionnel, mais, pas bête, la distribution MariaDB intègre XtraDB : la version Fork de InnoDB proposé par les excellentissimes Percona.

l’Open Database Alliance, qui est saluée par la communauté opensource, oeuvre manifestement pour soutenir MariaDB. C’est aussi une vraie réponse au risque que fait planer Oracle sur MySQL. La communauté autour de MariaDB semble assez dynamique et surtout grossir. Monty Widenius interviendra ce 12/13 novembre au Forum PHP Paris 2009 (AFUP).

Encore plein de questions, mais je n’hésiterai pas d’ores et déjà à recommander son utilisation.

Nest ce pas un dauphin qui plonge que je vois là ?

N'est ce pas un dauphin qui plonge que je vois là ?

Django Python and the meaning of Scrum

25 Oct 2009 at 07:32

pablo

méthodes agiles, opensource, python, scrum, technologies

3 Comments

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.

La fièvre (jaune) du post it

14 Oct 2009 at 12:33

pablo

méthodes agiles, scrum

No Comments

Post It F(or)ever

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.

Elgg, REST API

08 Oct 2009 at 14:57

pablo

php, technologies

No Comments

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');
?>
← Older Entries
Newer Entries →