La dette technique selon Uderzo & Goscinny

Hello, après avoir rapidement jetez un oeil du côté de la loi de Parkinson, voyons aujourd’hui la notion de dette technique. Pour l’historique de cette notion assez simple mais ô combien efficace : wikipedia. Grosso modo l’idée est que, à chaque fois que vous réalisez “à la vite” du développement (généralement parce que quelqu’un exige une date de livraison trop difficile à tenir et donc que la qualité disparaît, ou parce que vos pratiques de développement ne sont pas assez pointues -TDD, Unit Test, Pair programming, refactoring, etc-.) ce même code vous demandera de payer des intérêts à terme. A chaque fois que vous reviendrez sur ce code, une somme de travail supplémentaire due à sa mauvais qualité sera -en plus- nécessaire. Comme une vraie dette, celle-ci peut s’accumuler jusqu’à rendre complètement inerte une solution, un produit, etc. Rappelez vous bien que votre code n’est pas un capital mais est un coût : les plusieurs millions de lignes de code d’un code ne sont pas une richesse mais une contrainte.

Comme le montre ce diagramme (de Agilitrix 2010, ça tombe bien avec le thème… ) si vous ne résorbez pas la dette technique, vous obtiendrez un “dead core”. Un produit foutu.

Je viens de passer quelques jours en Suisse en mission, j’en profite afin de mieux exprimer cette idée de dette technique de faire appel aux idées de Uderzo & Goscinny : à chaque que vous laissez filer votre bout de pain, votre code, sans faire attention, vous accumulez du fromage partout dans votre application qui va -peut à peut-  l’empêcher d’avancer, jusqu’à un immobilisme certain (c’est l’application que vous jeterez dans le lac). Il est toujours difficile de convaincre les décideurs mais il est parfois nécessaire d’investir la résorption de la dette technique. (merci encore à Frédéric pour son inspiration). Cliquez sur l’image pour y accéder de façon lisible.

This entry was written by pablo, posted on April 12, 2011 at 1:48 pm, filed under gestion projet, management, méthodes agiles, technologies, XP and tagged asterix, dette technique, goscinny, obelix, uderzo, XP. Leave a comment or view the discussion at the permalink.

(Très) Petit panorama des portails Java

Juste un retour sur une petite analyse concernant les portails Java sur le marché actuellement. Je ne les connais pas tous naturellement, j’ai pu travaillé avec certains, sur d’autres je n’ai que des retours d’expériences récupérés par ci par là. Je ne me permettrai donc pas d’avoir un jugement définitif, mais en quelques mots je vous indique mon ressenti, si cela peut aider certaines personnes ?

Les nominés/accusés sont -par ordre alphabétique- :

eXo / GateIn

eXo -qui propose associé à son portail une suite ambitieuse : WCM, GED, suite collaborative, Knowledge suite, etc.- s’associe avec JBoss pour sortir GateIn. Version 3.0.0 beta 4 en ce moment même. Un produit orienté middleware si l’on croit sur parole le touilleur. Les retours d’expériences sont cependant alarmants. eXo/GateIn doit vite stabiliser son cycle de développement, son code, sa plate-forme pour être à la hauteur de ses ambitions (et renforcer son équipe).

Jalios

Une société française, un code propre, des retours d’expériences corrects, une solution probablement en devenir. à surveiller. à tester. à challenger.

Jahia

Le succès de la version 4, les erreurs de la version 5 : Jahia a manifestement fait de gros effort pour refactorisé son code, son produit. Ses forces sont ses faiblesses : son positionnement d’éditeur (avec une licence finalement pas donnée pour accéder à toutes les fonctionnalités), l’intégration du CMS dans le portail. Il faudrait désormais valider la pertinence de la version 6 et rentre les interfaces plus souples (on intègre GWT mais les portlets restent désespérement statiques). Commence à être bousculé par Lutèce ou Jalios.

JetSpeed2

Un beau labo. Pour faire des expériences donc.

Liferay

Constance et qualité sont les deux forces indiscutables de Liferay. Ce portail qui s’appuie désormais sur une communauté et un succès énorme se limite -pour l’instant- à être un portail, mais il le fait très bien. Son succès entraine d’autres succès : adhérences nombreuses, extensions nombreuses, etc. De très bons retours d’expériences.

Lutèce

Un portail, un CMS, de bons retours d’expérience. Une solution assez neuve qui doit faire ses preuves mais qui semble s’imposer au sein des collectivités (CMS). A surveiller, à évaluer.

uPortal

Très orienté universités et instituts de recherche aux US. Peu de retours ici, chez les frenchy.

This entry was written by pablo, posted on January 31, 2010 at 10:50 am, filed under java, opensource and tagged exo, gatein, jahia, jalios, java, jetspeed, liferay, lutece, opensource, portal, uportal. Leave a comment or view the discussion at the permalink.

Mais que manque-t-il à Java ?

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.

This entry was written by pablo, posted on December 2, 2009 at 5:36 pm, filed under java and tagged alfresco, apache, java, liferay, lucene, mysql, opensource, oracle, sun. Leave a comment or view the discussion at the permalink.

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.

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.