Elgg, plate-forme opensource de réseaux sociaux

Depuis 2 ou 3 jours je test sous l’impulsion de Yves (a qui je laisse la paternité de la sentence suivant : “On ne fait d’elgg sans casser des oeufs”) Elgg, la plate-forme opensource de réseaux sociaux. Inutile d’expliquer pourquoi les réseaux sociaux sont en plein boum, mais c’est le cas. Du coup, grande force de la communauté opensource, qui peut en irriter certains sur le plan idéologique, elle a décidé (la communauté) de sortir sa propre plate-forme (la meilleure R&D étant de lorgner chez le voisin). Elgg donc.

Basé sur PHP, a première vue le code parait surprenant, on ne voit pas immédiatement dans l’arborescence projet où se trouve quoi, et à quoi sert tel ou tel dossier. Tout ce qui se conçoit clairement se déploie clairement, et cette première impression reste mitigée. Je vous en dirais plus lorsque j’aurai vraiment essayé de toucher au code. Je suppose que cela est du au modèle de données : apparemment il a été prévu un modèle très malléable : j’introduis un nouveau type d’élément (une entité), je lui donne telle ou telle propriété avec telle ou telle valeur. Du coup demain si j’ai un élément de type nouveau, pas de problème, pas de modification de la structure des tables, ça roule. Bon, pour l’instant mon analyse est très superficielle donc sujette à caution. Je compte creuser et vous informer. Je ne sais pas si ce modèle n’a pas un impact sur les performances aussi, que je trouve un chouïa poussives (ils ont cependant prévu l’utilisation de memcached ou autre pour optimiser celles-ci). Idem pour le design, et le système de templates, je n’ai rien vu de concret jusqu’à présent. Enfin, un dernier petit point : l’installation se fait cahin-caha : il faut nécessairement activer le mod_rewrite de Apache. J’aurais préféré avoir le choix d’utiliser le rewrite ou non, cela pourrait faciliter le debug.

Bref il me faut creuser, car c’est malgré tout très prometteur (ah j’oubliais aussi de signaler  une API REST qui permet à l’accès à toutes les fonctions de l’outil, même si un warning indique qu’elle peut encore secouer un peu).

J’ai pu assez (très) rapidement monter une plate-forme, activer tout un tas de plugins à la facebook, twitter, pages, blog, albums photos, fichiers, etc. C’est du PHP/MySQL/Apache, donc cela reste simple (dans le bon sens du terme), efficace et productif. Aujourd’hui avec l’évolution des pratiques des internautes, et plus globalement des gens (voir des mobilonautes ou des iphonautes)  il parait évident que c’est le genre d’outil à déployer : communauté d’utilisateurs d’un logiciel, d’un produit, événementiel : par exemple un festival de musique, ou la convention des maraichers, ou l’université d’été du xxx (mettez le parti qui vous embauche)  : 3 mois avant la plate-forme est disponible, on chat, on blog avec les intervenants, avec les organisateurs, etc. durant l’événement c’est un vecteur en temps réel de l’actualité, a posteriori, c’est un outil de rétrospective (fichiers liés, blogs,images, etc.).

Bref, pas mal de projets assez excitants autour en perspective, j’espère du moins. Si vous souhaitez tester un peu la plate-forme vous pouvez aller chez Elgg.org ou me demander de vous créer un compte pour elgg.areyouagile.com (en me contactant pablo point pernot arboase gmail point com). C’est la plate-forme de test dont je vous parlais. Attention actuellement vu de l’extérieur elle paraît très creuse car nous avons ajouté un pluggin (walledgarden) qui interdit l’accès du public aux infos.

This entry was written by pablo, posted on September 25, 2009 at 7:48 am, filed under opensource, php, technologies and tagged apache, elgg, opensource, php, réseau social, social network. Leave a comment or view the discussion at the permalink.

Eclipse, haine et amour

Là là, làlàlà impitoyyaabllleeuuuu !

Non, désolé, mais cela ressemble fort à un post inutile (que les gens sensés s’arrêtent ici svp)*. Je ne cesse d’utiliser et de ne pas utiliser Eclipse. Je tergiverse devant l’éternelle question ultime du développeur dont la vie se résume à quelques bits : mais bon sang mais bien sûr quel éditeur (de code) vais-je donc utiliser ? Dans l’opensource (comme on dit “chez les restaurateur”) l’empreinte mémoire, c’est à dire la place prise en mémoire par un processus, c’est très important. On regarde de haut un outil gourmand. Et bon sang Eclipse, et Java plus généralement, sont de sacrés consommateurs de mémoire. D’où ma résistance (souvent enfoncée) à Eclipse (faut-il rappeler que je ne développe que très rarement en Java, mais surtout en PHP, voire en Python**). Cette “lourdeur mémoire” est à mon avis un des éléments fondateurs de ce désamour qui existe depuis longtemps entre l’Opensource et Java. Mais bon, Eclipse a tout pour séduire : références croisées d’un simple clique, découpage des objets (outline), lucène, tout un tas de plugins puissants et j’en passe, cerise sur le gâteau avec XDebug embarqué le tatonnement pas à pas dans le code est un délice. Mais je m’égare, ma machine râme, pédale, crachote, je fais un top (* commande unix/linux qui indique les processus en cours et leurs consommations CPU et mémoire), et je m’étouffe ! P***n java, p****n Eclipse. Ni une, ni deux, je bascule sur gedit (avec ctags). Là c’est léger, c’est rapide. Et puis j’erre dans le code, le teint pâle, le regard morne, où sont donc passés toutes ces fonctionnalités pratiques et efficaces, en un mot productives… Allez essayons Eclipse, l’éternel recommencement***.

This entry was written by pablo, posted on September 22, 2009 at 7:14 pm, filed under opensource, technologies and tagged eclipse, gedit, java, lucene, opensource, php, python. Leave a comment or view the discussion at the permalink.

Scrum : un écueil pour les SSII ? et Kanban ?

Kanban board

Appliquer Scrum n’est pas simple, surtout pour les SSII. L’un des principaux facteurs dont je souffre actuellement est la stabilité des équipes. les impératifs de production, eux-mêmes menés par des impératifs financiers règnent trop souvent en maîtres, et c’est normal. C’est aussi le signe me direz-vous que les processus et les méthodes ne sont pas assez matures puisqu’au moindre coup de vent (un gros contrat signé, une régie déclenchée pour un élément clef de l’équipe, etc.) ils volent en éclats. Je ne peux pas vous contre-dire. Je n’ai pas eu la chance de connaitre une entreprise qui -quelque soit le contexte (la crise par exemple)-  soit capable de maintenir coûte que coûte l’intégralité de ses processus tout en les faisant progresser (ces derniers mots sont importants sinon c’est la fossilisation qui vous guette).

Aujourd’hui beaucoup de SSII se jettent sur les méthodes agiles car elles ont le vent en poupe. Elles se heurtent à de nombreuses problématiques avec, pour n’en citer que quelques unes :

• la contractualisation (le  problème majeur actuellement, puisque ce n’est que le début de leur offre dans ce domaine, et que c’est un élément très fondateur,),  ils leur faut trouver une troisème voie entre le forfait et la régie (merci Christophe).
• la redistribution des rôles : le client (product owner) est responsable, l’équipe (team) est responsable, le Chef de projet disparaît, il était le responsable, le fusible, Atlas qui portait le projet (accessoirement avec le directeur de projet) ; le Scrummaster apparaît, il est un facilitateur, mais nullement un responsable.
• la stabilité des équipes durant les sprints, les itérations, est nécessaire.
• la maturité des clients et des équipes, personne n’est interchangeable, chaque collaborateur est différent d’un autre, etc.

Les SSII entament donc un difficile périple. Aujourd’hui si je regarde l’un des projets que je pousse vers l’agilité je me heurte de plein fouet à la difficulté de la stabilité de l’équipe. Il ne s’agit pas d’un projet client, mais d’un projet interne. Il est d’autant plus saccadé. Sa priorité est difficile à établir. Les ressources affluent (fin de projets clients) et elles refluent (signature de projets clients). Moi même je ne peux avoir qu’une activité chaotique à son encontre. Appliquer les fondements de Scrum dans ce contexte devient très compliqué. Mais l’agilité c’est aussi une dynamique de l’adaptation. Je me tourne donc aujourd’hui pour ce projet vers Kanban.

Pourquoi ? Il me propose des valeurs qui sont en adéquations avec mes besoins (certains sont aussi associées à Scrum), ne pas développer de fonctionnalité que personne ne va utiliser, ne pas écrire plus de specs qu’il n’y aura de code, ne pas écrire plus de code que je ne puisse tester, ne pas tester plus de code que je ne puisse déployer. Très concrètement ne pouvant bâtir une équipe stable, ne pouvant garantir de daily scrum journalier, n’ayant pas assez de garanties sur la pérennité de mon équipe, etc. je vais me focaliser sur ce que j’imagine être l’essentiel de la pratique Kanban et à partir de là reconstruire un processus agile (si cela marche). Soyons clair, il permet surtout de simplifier excessivement le processus, et si cela fonctionne il me permettra de rebondir sur quelque chose de plus puissant. Ceci dans le cadre de ce projet.

Je ne sais plus où (ah si, ici)  j’ai lu cet exemple mais en gros, de façon imagée : je pose des portes sur une voiture (Kanban vient -encore- de Toyota), j’ai un tas de 10 portes devant moi, lorsque j’arrive à la 5ème porte je vois une étiquette sur la voiture (étiquette = kanban en japonais). L’étiquette m’indique que je dois prévenir la personne qui fabrique les portes de me fabriquer 10 portes supplémentaires. Je trouve cette personne et lui demande 10 portes supplémentaires. Elle arrête la tâche qu’elle était en train de réaliser, et commence à fabriquer 10 portes supplémentaires. Elle savait que je passerais, mais travaillait sur autre chose. Je retourne à mon assemblage. Lorsque je finis presque mon tas de 10 portes, la personne a qui j’avais demandé les nouvelles portes arrive, elle dépose les portes, et naturellement, sur la 5ème, au milieu du tas, une petite étiquette est présente.etc.

Ici, sur ce fameux projet interne, je dispose d’un backlog et d’une équipe fluctuante dont la disponibilité est fluctuante.Ma difficulté est le WIP (Work in progress). Je ne dois pas avoir un membre de l’équipe qui démarre quelque chose et qui malheureusement ne peut l’achever (pour x raisons). Sinon je me retrouve avec une tâche de coordination (du nouveau membre remplacé par l’ancien), de transfert de compétences (du nouveau …) , et potentiellement de rework (le nouveau membre de l’équipe aborde différemment la résolution de sa tâche). Bref 3 plaies essentielles sources de gaspillage.

Mon objectif est de définir des User Story (ou MMF : minimal marketable feature) assez compactes et assez indépendantes les unes des autres pour qu’elles puissent être abordées unitairement et assez rapidement : pour ne pas risquer de perdre l’acteur qui l’a prise en charge, pour qu’il puisse appréhender la MMF rapidement. Avoir assez de visibilité sur l’ensemble des MMF pour qu’elles puissent s’enchainer et constituer de la valeur ajoutée. Faire des livraisons plus rapidement, plus rythmées. Quand un flux régulier sera mis en place j’aurais mis en place un premier niveau d’efficacité. L’objectif de ce flux est de réussir à créer un rythme et une régulation entre les différentes tâches liées au projet, en limitant au maximum le “work in progress” car c’est lui qui m’empêche de livrer régulièrement et qui rigidifie la marche du projet. Chaque tâche s’emboite avec d’autres, ou peut en déclencher d’autres sans que les personnes qui aient la charge de ces autres tâches ne soient impactées. Elles ont donc du “temps libre” pour leurs autres activités (sachant qu’ici le procédé est inversé, c’est quand elles ont du temps libre qu’elles se consacrent au projet “interne”) . Enfin il est plus aisé d’intervenir sur le projet quand chaque tâche est plus compacte (ceci n’est malheureusement pas si simple et pas si souvent vrai).

D’ici là, et si j’atteins ce but… nous en reparlerons.

Pour en savoir plus sur Kanban, appelez Google, ou utilisez cette page de cet excellent blog : targetprocess : kanban.

This entry was written by pablo, posted on September 20, 2009 at 8:36 am, filed under kanban, scrum and tagged backlog, kanban, management, scrum, sensibilisation, work in progress. Leave a comment or view the discussion at the permalink.

MySQL dans la tourmente mais toujours en progrès

MySQL

Où en est MySQL ? en plein paradoxe a priori. D’abord les choses qui fâchent : La société est rachetée voilà à peu près 1 an et demi par SUN. Manifestement elle reste KO debout. On ne connait ni la roadmap qu’envisage Sun, ni si ils vont garder le modèle économique de la base de données opensource la plus répandue au monde. En décidant un silence radio de 6 mois suivant le rachat Sun n’arrange rien. Et ça bouge, en interne, certaines grosses pointures quittent le navire. Pas mal de choses assez excitantes semblent oubliées ou dans une impasse : par exemple Google devait intervenir sur une partie du code de MySQL (des plugins de recherches et d’analyses syntaxiques probablement), disparu, oublié. Heureusement rassurent certains, Sun est une boite qui va comprendre MySQL, et ce n’est pas l’un des gros comme Oracle ou Microsoft ou IBM. A ce sujet -bien embarrassé d’avoir laissé filer InnoDB chez l’ennemi (racheté par Oracle il ya quelques années)- MySQL s’est lancé dans la réalisation d’un moteur transactionnel maison : Falcon. Démarrage poussif de ce dernier qui reste encore en Alpha et dont les progrès paraissent trop lents pour rassurer. On se demande même si il n’est pas gelé. Compétition en interne, on sent bien que les ingénieurs de Sun ont décidés de se la jouer “pro” contre les savants fous créatifs de la communauté (si je caricature). Ca remue je vous dis. Monty Widenius se lance dans Maria (un moteur de stockage myisam évolué), en sent bien qu’il est exclu, il ne tarde pas à quitter MySQL, et fonde récemment avec les excellentissimes Percona l’Open Database Alliance. Et patatras, voilà 6 mois, Oracle rachète Sun… Et c’est reparti pour un tour : pas de visibilité, pas de plan, l’inconnu.

Drizzle

Et pourtant beaucoup de bonnes choses : malgré un silence insistant de 6 mois les ingénieurs de chez Sun sortent soudain une version 5.4 de MySQL qui, si l’on en croit les benchmarks, pulvérisent les performances de ses prédécesseurs. On commence aussi à comprendre la position de Sun concernant le marché : ils offrent des solutions packagés/optimisés hardware/serveur de données. Et puis Oracle, ni Sun, n’osent bouger : le moteur Maria est déjà devenu un projet opensource à part, Percona offre des releases de MySQL patchées et propose aujourd’hui son propre moteur stockage et son propre outil de backup basés sur InnoDB. Drizzle (là aussi des anciens de MySQL) apparaît (comme très prometteur). Bref au moindre mouvement la communauté risque de faire un fork, si ce n’est déjà le cas.

Enfin autour de ma petite fenêtre je vois bien que les projets opensource n’ont jamais eu autant de succès, je vois bien que MySQL pénètre chez des clients qui ne juraient jusqu’à présent que par Oracle ou DB2.

This entry was written by pablo, posted on September 11, 2009 at 5:38 am, filed under database, opensource and tagged db2, drizzle, google, innodb, monty widenius, mysql, open database alliance, opensource, oracle, sun. Leave a comment or view the discussion at the permalink.

De l’importance de la transparence (sans question morale)

La notion de transparence est très importante dans les méthodes agiles type Scrum (mais pas uniquement là). C’est une façon d’être (être transparent) qui devrait être appliquée dans tous les cas (Agile, CMMI, qu’importe même aux projets sans méthode). Chez Scrum on associe la notion de transparence a celle de courage il me semble, sous-entendu : qui aurait envie d’aller se confronter à un client pour lui annoncer une très mauvaise nouvelle, ou qui a envie de prendre le risque de dénoncer le fait qu’il a échoué, etc, ce n’est jamais simple mais c’est essentiel.

Le mot courage est assez parlant, il faut l’associer dans notre cas à la maturité, l’expérience. A mon avis le courage de la transparence vient avec les années, avec l’expérience. Mais ici nulle question de moralité contrairement a ce que pourrait sous-entendre transparence que l’on rapprocherait de honnêteté, mais juste de réalisme économique, bref lorsque l’on travaille dans le privé : de maturité ! En effet, et c’est pourquoi j’insiste sur le fait que cela n’est pas exclusivement lié aux projets agiles, le fait de ne pas être transparent avec son client aboutira systématiquement par une perte de productivité et d’efficacité. Au plus tôt une anomalie est décelée, au plus tôt elle doit être traitée, au plus tôt un quiproquo voit le jour, au plus tôt il faut lever celui-ci. Tout ce qu’on laisse en chemin de façon délibérée (opaque) se retrouvera nécessairement sur notre route plus tard, et devra être traité avec des coûts plus élevés sans nul doute. C’est pour cela que je parle de productivité et d’efficacité au travers de la transparence. C’est une notion révélée par les méthodes agiles car elles nous obligent -par une constante itération et par mise à nu fréquente des résultats- à être transparent.

Suis-je clair ?

Je rebondis en fait sur un commentaire réalisé ce jour ici.

This entry was written by pablo, posted on September 8, 2009 at 6:41 pm, filed under méthodes agiles and tagged courage, efficacité, honnêteté, productivité, scrum, transparence. Leave a comment or view the discussion at the permalink.