Blog entries by Nicolas Chauvat [3]
  • KanbanDay 2015

    2015/06/02 by Nicolas Chauvat

    Nous étions plusieurs personnes de Logilab à participer au KanbanDay ce jeudi 28 mai 2015 à Paris.

    Management Visuel

    La présentation que j'ai préféré est 1+9 outils de management visuel de Damien Thouvenin. Le support comme l'orateur étaient clairs et agréables.

    Au-delà d'une sorte de catalogue d'outils, j'en retiens que le but du management visuel est de montrer l'écart par rapport à la situation espérée et non de fournir un ensemble d'informations qui permettent de comprendre dans le détail la situation. Le management visuel est un moyen, pour ceux qui produisent, de s'assurer qu'ils restent sur la trajectoire prévue. Les indicateurs mis en place doivent donc être choisis en fonction de l'objectif fixé et de la trajectoire choisie pour l'atteindre. Dans le cas d'une dérive, il sera nécessaire de chercher des explications et d'identifier les problèmes à la racine, mais ce n'est pas le rôle du tableau de bord utilisé au quotidien que de présenter tous les détails du fonctionnement de votre système de production.

    Une analogie simple serait que dans votre voiture, le compteur de vitesse vous permet de contrôler le résultat d'une pression sur l'accélérateur ou le frein, mais qu'en cas de problème, il vous faudra ouvrir le capot pour déterminer la panne.

    La principale lecture recommandée a été L'usine s'affiche.

    /file/293145/raw

    Gribouille Académie

    Je me suis bien amusé à l'atelier Gribouille académie. Après avoir vu des personnes dessiner des résumés de présentations lors de conférences et avoir été agréablement surpris de découvrir l'efficacité du prototypage papier lors d'une récente formation "Lean UX", j'avais envie d'explorer la prise de note graphique.

    S'il est vrai qu'il n'est pas nécessaire de faire une école d'art pour faire des gribouillages, être capable d'obtenir un résultat plaisant en peu de temps demande du travail et de l'entraînement... mais ce n'est pas surprenant, puisque comme le disent nos amis d'outre-océan, il n'y a pas de repas gratuit.

    /file/293142/raw

    Plénières

    Les présentations en séances plénières m'ont donné quelques idées à creuser.

    La première idée concerne l'allocation partielle de ressources, qui est bien décrite dans la bibliographie Lean au sujet du taux d'occupation des machines et pourrait se traduire dans le domaine du développement logiciel par l'affectation de 10% à 20% des ressources à "toutes les tâches qui surviendront et pourraient permettre aux autres membres de l'équipe de ne pas rester bloqués ou de ne pas être ralentis". Une des difficultés est de savoir à qui faire payer ce temps dans le cadre de développements au forfait, surtout si la réserve de capacité est partagée entre plusieurs projets.

    La deuxième idée est plus difficile à formuler mais pourrait se résumer par "essayer de faire parfaitement une tâche bien définie fait aller moins loin qu'essayer d'aller le plus loin possible". Dans la présentation, le titre était "viser la perfection ou viser l'excellence".

    /file/293141/raw

    La troisième idée est le rapport entre agilité et enseignement. Je me suis déjà intéressé de près à la pédagogie Montessori et à la classe inversée (dont la Kahn Academy est un exemple. Sachez aussi que le premier congrès français de classe inversée aura lieu début juillet à Paris), j'ai suivi plusieurs cours en ligne (MOOC), donc j'étais en terrain connu quand Christian den Hartig, un professeur de français de collège, a expliqué comment il applique les principes de l'agilité dans sa classe. Nous faisons beaucoup de formation à Logilab et je me demande comment nous pourrions faire évoluer ou diversifier notre offre pour y intégrer ces idées.

    Autres ressources

    Je connaissais déjà les jeux présentés, mais je note que KanbanZine est une version améliorée de GetKanban. Il en existerait une version libre, mais je ne l'ai pas encore trouvée. Une des qualités de ce jeu quand il est joué à plusieurs équipes qui se concurrencent est de souligner la différence entre estimation de la valeur et estimation de la charge.

    Au rayon bouquiniste, j'ai apprécié la lecture du "Guide du chefs de produit", pardon, du "Guide des Product Managers et des Products Owners d'élite" offert par Thiga et j'espère que Christophe Keromen, de CoActiv, pensera à m'envoyer sa bibliographie de Bob l'Eponge.

    Conclusion

    Merci à l'équipe d'organisation de KanbanDay, je n'ai pas perdu mon temps en y consacrant ma journée du 28 mai 2015.


  • Deuxième hackathon codes libres de mécanique

    2014/04/07 by Nicolas Chauvat

    Organisation

    Le 27 mars 2014, Logilab a accueilli un hackathon consacré aux codes libres de simulation des phénomènes mécaniques. Etaient présents:

    • Patrick Pizette, Sébastien Rémond (Ecole des Mines de Douai / DemGCE)
    • Frédéric Dubois, Rémy Mozul (LMGC Montpellier / LMGC90)
    • Mickaël Abbas, Mathieu Courtois (EDF R&D / Code_Aster)
    • Alexandre Martin (LAMSID / Code_Aster)
    • Luca Dall'Olio, Maximilien Siavelis (Alneos)
    • Florent Cayré, Nicolas Chauvat, Denis Laxalde, Alain Leufroy (Logilab)

    DemGCE et LMGC90

    Patrick Pizette et Sébastien Rémond des Mines de Douai sont venus parler de leur code de modélisation DemGCE de "sphères molles" (aussi appelé smooth DEM), des potentialités d'intégration de leurs algorithmes dans LMGC90 avec Frédéric Dubois du LMGC et de l'interface Simulagora développée par Logilab. DemGCE est un code DEM en 3D développé en C par le laboratoire des Mines de Douai. Il effectuera bientôt des calculs parallèles en mémoire partagée grâce à OpenMP. Après une présentation générale de LMGC90, de son écosystème et de ses applications, ils ont pu lancer leurs premiers calculs en mode dynamique des contacts en appelant via l'interface Python leurs propres configurations d'empilements granulaires.

    Ils ont grandement apprécié l'architecture logicielle de LMGC90, et en particulier son utilisation comme une bibliothèque de calcul via Python, la prise en compte de particules de forme polyhédrique et les aspects visualisations avec Paraview. Il a été discuté de la réutilisation de la partie post/traitement visualisation via un fichier standard ou une bibliothèque dédiée visu DEM.

    Frédéric Dubois semblait intéressé par l'élargissement de la communauté et du spectre des cas d'utilisation, ainsi que par certains algorithmes mis au point par les Mines de Douai sur la génération géométrique d'empilements. Il serait envisageable d'ajouter à LMGC90 les lois d'interaction de la "smooth DEM" en 3D, car elles ne sont aujourd'hui implémentées dans LMGC90 que pour les cas 2D. Cela permettrait de tester en mode "utilisateur" le code LMGC90 et de faire une comparaison avec le code des Mines de Douai (efficacité parallélisation, etc.).

    Florent Cayré a fait une démonstration du potentiel de Simulagora.

    LMGC90 et Code_Aster dans Debian

    Denis Laxalde de Logilab a travaillé d'une part avec Rémy Mozul du LMGC sur l'empaquetage Debian de LMGC90 (pour intégrer en amont les modifications nécessaires), et d'autre part avec Mathieu Courtois d'EDF R&D, pour finaliser l'empaquetage de Code_Aster et notamment discuter de la problématique du lien avec la bibliothèque Metis: la version actuellement utilisée dans Code_Aster (Metis 4), n'est pas publiée dans une licence compatible avec la section principale de Debian. Pour cette raison, Code_Aster n'est pas compilé avec le support MED dans Debian actuellement. En revanche la version 5 de Metis a une licence compatible et se trouve déjà dans Debian. Utiliser cette version permettrait d'avoir Code_Aster avec le support Metis dans Debian. Cependant, le passage de la version 4 à la version 5 de Metis ne semble pas trivial.

    Voir les tickets:

    Replier LibAster dans Code_Aster

    Alain Leufroy et Nicolas Chauvat de Logilab ont travaillé à transformer LibAster en une liste de pull request sur la forge bitbucket de Code_Aster. Ils ont présenté leurs modifications à Mathieu Courtois d'EDF R&D ce qui facilitera leur intégration.

    Voir les tickets:

    Suppression du superviseur dans Code_Aster

    En fin de journée, Alain Leufroy, Nicolas Chauvat et Mathieu Courtois ont échangé leurs idées sur la simplification/suppression du superviseur de commandes actuel de Code_Aster. Il est souhaitable que la vérification de la syntaxe (choix des mots-clés) soit dissociée de l'étape d'exécution.

    La vérification pourrait s'appuyer sur un outil comme pylint, la description de la syntaxe des commandes de Code_Aster pour pylint pourrait également permettre de produire un catalogue compréhensible par Eficas.

    L'avantage d'utiliser pylint serait de vérifier le fichier de commandes avant l'exécution même si celui-ci contient d'autres instructions Python.

    Allocation mémoire dans Code_Aster

    Mickaël Abbas d'EDF R&D s'est intéressé à la modernisation de l'allocation mémoire dans Code_Aster et a listé les difficultés techniques à surmonter ; l'objectif visé est un accès facilité aux données numériques du Fortran depuis l'interface Python. Une des difficultés est le partage des types dérivés Fortran en Python. Rémy Mozul du LMGC et Denis Laxalde de Logilab ont exploré une solution technique basée sur Cython et ISO-C-Bindings. De son côté Mickaël Abbas a contribué à l'avancement de cette tâche directement dans Code_Aster.

    Doxygen pour documentation des sources de Code_Aster

    Luca Dall'Olio d'Alneos et Mathieu Courtois ont testé la mise en place de Doxygen pour documenter Code_Aster. Le fichier de configuration pour doxygen a été modifié pour extraire les commentaires à partir de code Fortran (les commentaires doivent se trouver au dessus de la déclaration de la fonction, par exemple). La configuration doxygen a été restituée dans le depôt Bitbucket. Reste à évaluer s'il y aura besoin de plusieurs configurations (pour la partie C, Python et Fortran) ou si une seule suffira. Une configuration particulière permet d'extraire, pour chaque fonction, les points où elle est appelée et les autres fonctions utilisées. Un exemple a été produit pour montrer comment écrire des équations en syntaxe Latex, la génération de la documentation nécessite plus d'une heure (seule la partie graphique peut être parallélisée). La documentation produite devrait être publiée sur le site de Code_Aster.

    La suite envisagée est de coupler Doxygen avec Breathe et Sphinx pour compléter la documentation extraite du code source de textes plus détaillés.

    La génération de cette documentation devrait être une cible de waf, par exemple waf doc. Un aperçu rapide du rendu de la documentation d'un module serait possible par waf doc file1.F90 [file2.c [...]].

    Voir Code Aster #18 configure doxygen to comment the source files

    Catalogue d'éléments finis

    Maximilien Siavelis d'Alneos et Alexandre Martin du LAMSID, rejoints en fin de journée par Frédéric Dubois du LMGC ainsi que Nicolas Chauvat et Florent Cayré de Logilab, ont travaillé à faciliter la description des catalogues d'éléments finis dans Code_Aster. La définition de ce qui caractérise un élément fini a fait l'objet de débats passionnés. Les points discutés nourriront le travail d'Alexandre Martin sur ce sujet dans Code_Aster. Alexandre Martin a déjà renvoyé aux participants un article qu'il a écrit pour résumer les débats.

    Remontée d'erreurs de fortran vers Python

    Mathieu Courtois d'EDF R&D a montré à Rémy Mozul du LMGC un mécanisme de remontée d'exception du Fortran vers le Python, qui permettra d'améliorer la gestion des erreurs dans LMGC90, qui a posé problème dans un projet réalisé par Denis Laxalde de Logilab pour la SNCF.

    Voir aster_exceptions.c

    Conclusion

    Tous les participants semblaient contents de ce deuxième hackathon, qui faisait suite à la première édition de mars 2013 . La prochaine édition aura lieu à l'automne 2014 ou au printemps 2015, ne la manquez pas !


  • Réseau social ouvert et distribué avec CubicWeb

    2012/07/18 by Nicolas Chauvat

    Qu'est-ce qu'un réseau social ?

    • descriptions de personnes (profil, histoire, etc)
    • liens avec les autres membres (carnet adresses, etc)
    • création de groupes
    • partage de contenu (photos, vidéos, présentations, etc)
    • discussion (blog, commentaires, forums, messages, microblog)
    • mise en relation (boulot, ludo, dodo, etc)
    • recommandation (lien, livre, achat, film, music, etc)
    • présence (fait quoi, avec qui, où, etc)

    Et l'interopérabilité ?

    • nombreuses applications / plate-formes
    • en majorité centralisées et fermées
    • ouverture progressive: protocoles et API en cours de dév
    • réseaux ouverts et distribués: appleseed, diaspora, onesocialweb, etc.
    • pourrait-on faire autrement ?

    API: openstack

    • découverte / discovery = xrd
    • identité / identity = openid
    • contrôle d'accès / access control = oauth
    • activités / streams = activity streams
    • personnes / people = portable contacts
    • applications = opensocial

    Et en utilisant les standards du Web ?

    Architecture ouverte et distribuée

    • vocabulaires RDF et protocole HTTP + REST
    • chacun son serveur
    • GET et éventuellement copie locale
    • abonnement si nécessaire (pubsub, xmpp, atom ?)
    • permissions gérées localement

    => social semantic network

    Pourquoi CubicWeb ?

    • plate-forme pour web sémantique (semantic web framework)
    • conçu pour avoir composants à assembler
    • chacun peut définir son application sur mesure
    • fait pour publier html et rdf en parallèle
    • fait pour exporter et importer données
    • déjà foaf, skos, sioc, doap, rss, atom, etc.

    Exemple

    • (micro)blog + book + link + file
    • pourrait ajouter: musique, photos, etc.
    • mais aussi: journal, recherche appartement, etc.

    Et ensuite ?

    Il y a bien longtemps...

    • découverte = who et cat /etc/passwd | cut -d: -f1
    • identité = login
    • contrôle accès = chmod, chgrp, su
    • activités = .plan
    • personnes = .addressbook
    • applications = vim ~/public_html/me.html

    Note

    Ce texte a été présenté en août 2010, lors de la conférence française des utilisateurs de Python (PyCon-Fr 2010)


  • 12 ans de l'April: bilan et objectifs

    2009/04/05 by Nicolas Chauvat
    http://www.april.org/themes/zen/zen_april/images/logo.png

    L'April fête cette année ses douze ans. L'association de promotion et de défense du logiciel libre approche maintenant les 5000 membres, toutes catégories confondues: personnes physiques, entreprises commerciales, collectivités, associations. Elle vient de publier son rapport moral 2008 et sa feuille de route 2014 qui fixe des objectis pour les cinq années à venir. On notera en particulier la lutte contre les quatre dangers que sont les brevets sur les algorithmes, les dispositifs de contrôle d'usage, la vente liée et l'informatique déloyale. Consultez le site de l'April pour en savoir plus sur ses actions et n'hésitez pas à adhérer ou à donner quelques heures de votre temps.


  • Fusionner dans le bon sens avec mercurial

    2008/11/27 by Nicolas Chauvat
    http://www.selenic.com/hg-logo/logo-droplets-50.png

    Contrairement à ce que l'on pourrait penser a priori, il y a un bon et un mauvais sens pour fusionner deux têtes dans en entrepôt mercurial.

    Prenons un exemple et admettons que l'on parte d'une révision 123. Alfred, Barnabé et Coruscant font des changements qui produisent l'arbre suivant:

    123 -> 124 -> 125 ---> 126 -> 129 --> 130
                       \-> 127 -> 128 /
    

    Si dans le même temps, Zoé part de la révision 123 et produit l'arbre:

    123 -> 131
    

    quand Zoé va vouloir faire son hg push sur l'entrepôt partagé, elle va avoir le message "ça crée des têtes, est-ce que vous êtes sûr de vouloir faire ce push". Zoé va se dire qu'il vaut mieux commencer par un 'pull' et un 'merge', mais c'est là qu'il faut se méfier.

    En effet, si Zoé est sur la révision 131 et qu'elle fusionne avec 130, le changeset sera énorme car il contiendra tous les changements qui permettent de passer de 123 à 130. En revanche, si Zoé passe sur la 130 et fusionne avec la 131, elle n'aura que les changements qu'elle vient d'apporter. Dans le premier cas, le 'merge' sera difficile à comprendre, alors qu'il sera bien plus simple dans le second.

    Au final, comment faire la fusion dans le "bon" sens ?

    1/ hg push -> ah tient, ça crée des têtes, donc je ne le fais pas

    2/ hg pull -u ou hg pull suivi de hg merge -> y'a eu un merge

    3/ hg status -> beaucoup de fichiers modifiés... oulàlà, c'est bizarre je vais regarder

    4/ hgview -> ah oui, sur l'autre tête y'a beaucoup plus de changements, donc je vais plutôt faire le 'merge' dans l'autre sens

    5/ hg up -C ab123_autre_tete -> je me retrouve sur l'autre tête

    6/ hg merge cd456_ma_tete -> un joli 'merge'

    7/ hg status -> seulement quelques fichiers modifés, voilà qui est mieux

    8/ hg ci -m merge -> youpi, je valide cette fusion

    9/ hg push -> tagada, je partage avec mes voisins

    Moralité: faites des hg status et des hgview aussi souvent que nécessaire pour préparer vos commits et parvenir à un historique facile à comprendre.

    Remarque: on peut aussi remplacer les étapes 5, 6 et 7 par hg diff -r ab123_autre_tete -r cd456_ma_tete pour afficher le diff de ma_tete par rapport à autre_tete, car l'opération de fusion doit être symétrique et donner le même résultat qu'on la lance depuis l'une ou l'autre tête, même si l'affichage par défaut de hg status et hg diff dépend de la tête qui constitue le premier parent (l'étape 5 ayant justement pour effet de changer ce premier parent).