subscribe to this blog

Logilab.org - en VF

Des nouvelles de Logilab et de nos projets sous licences libres, ainsi que des sujets qui nous tiennent à cœur (Python, Linux, Debian, le web sémantique, le calcul scientifique...)

back to pagination (10 results)
  • Les objectifs et l'histoire des présentations internes "5mintalk"

    2019/04/16 by Arthur Lutz

    Le partage de la connaissance est une composante importante à Logilab. Elle se décline en de nombreux formats dont je ne pourrais pas faire une liste exhaustive, parmi lesquels : la documentation interne, les communautés de logiciel libre, les listes de discussion, stackoverflow ou autres supports de ce type, l'organisation ou la participation à des conférences techniques et meetup en tant qu'auditeur ou en tant qu'orateur... et les "5mintalks".

    Les 5mintalk sont des présentations internes à Logilab, qui durent rarement 5 minutes et visent les objectifs suivants :

    • partager sa connaissance et diffuser les bonnes pratiques ;
    • faire connaître les atouts et les difficultés d'un projet aux autres salariés ;
    • faire des point d'étape sur des nouveautés liées aux services internes ;
    • fournir un moment d'attention partagé pour une entreprise distribuée sur deux sites géographiques (Paris et Toulouse) et de nombreuses personnes en télétravail (Nantes, Valence, Nice) ;
    • fournir un "espace protégé et bienveillant" pour que les personnes puissent s'exercer à la prise de parole en public, ce qui peut ensuite se transformer en prise de parole en public dans le cadre de conférences ;
    • s'entraîner à synthétiser et transmettre ses idées.

    Tout cela se fait sur la base du volontariat.

    Depuis 2018, nous utilisons de plus en plus la visioconférence pour faire ces présentations, afin que les personnes en télétravail et les sites géographiques distribués puissent les suivre.

    Depuis 2018 aussi, nous encourageons et nous formons à l'enregistrement de ces présentations sous forme de screencast pour que les absents puissent bénéficier de ces contenus en différé. Ces contenus sont ensuite partagés sur une instance peertube interne (peertube est un formidable logiciel de partage vidéo). Ces contenus peuvent aussi être utiles aux nouvelles recrues.

    https://www.logilab.org/file/10131502/raw/peertube.png

    Bien qu'on nous le demande parfois, ces contenus ne sont pas visibles de l'extérieur pour deux raisons principales. La première est l'aspect "espace protégé", qui permet l'expérimentation, alors qu'un certain niveau de qualité serait requis pour un publication externe. Avant de publier sur notre peertube interne, les personnes redemandent souvent pour vérifier que ce ne sera pas rendu public. La seconde raison est que nous faisons librement référence aux projets clients et à la manière dont ils sont réalisés, en incluant des détails qui ne sont pas partageables à l'extérieur.

    Les contenus sont très variés :

    • nos pratiques techniques ;
    • notre veille technologique ;
    • métiers de certains projets clients ;
    • retour suite à une conférence ;
    • activités en dehors du cadre professionnel.

    Vous pouvez retrouver la description succincte du contenu des présentations sur le mot-dièse #5mintalk sur notre instance mastodon, pour participer à ces échanges de pratiques... rejoignez nous.


  • Retour sur le Workshop Prometheus et Grafana - Nantes 2019

    2019/03/08 by Arthur Lutz

    Hier soir j'ai participé à un workshop/meetup sur Prometheus et Grafana co-organisé par le Meetup Nantes Monitoring et le Meetup Cloud Native Computing Nantes.

    Le workshop était super bien préparé sous forme d'un dépôt git avec des instructions, des questions, des solutions : https://github.com/samber/workshop-prometheus-grafana Si ces technos vous intéressent, je vous encourage vivement à dérouler ce workshop.

    https://www.logilab.org/file/10131298/raw/Screenshot%20from%202019-03-08%2010-23-11.png

    J'ai parcouru la liste des exporters https://prometheus.io/docs/instrumenting/exporters/

    La liste des exporters qui pourraient nous intéresser à Logilab (technologies qu'on utilise) :

    On a aussi discuté avec des membres du workshop d'autres outils de métriques :

    Pour avoir des storage-schema.conf comme dans graphite, il faut avoir plusieurs prometheus qui se "scrape" les uns les autres avec des schémas de rétention et de granularité différents.

    Apparemment prometheus n'est pas facile à scaler, cortex est un projet qui essaye de le faire : https://www.cncf.io/blog/2018/12/18/cortex-a-multi-tenant-horizontally-scalable-prometheus-as-a-service/

    Bref, un excellent meetup mené avec brio par Samuel Berthe et Mickael Alibert. Merci à Epitech Nantes pour l'acceuil et à Zenika pour l'apéro à la fin du workshop.


  • Rencontres Debian Nantes - janvier 2019

    2019/01/30 by Arthur Lutz

    Le mardi 29 janvier 2019 entre 19h à 21h, des contributeurs et utilisateurs de Debian se sont rencontré pour échanger sur Debian. Debian est un système d'exploitation libre pour votre ordinateur. Un système d'exploitation est une suite de programmes de base et d’utilitaires permettant à un ordinateur de fonctionner.

    Merci à Capensis pour l’accueil dans ses locaux.

    Trois présentations ont été faites :

    https://social.logilab.org/system/media_attachments/files/000/083/740/original/fdb79bdc819cb6f6.png

    On a aussi parlé de l'association Debian France qui soutien nos rencontres. Rendez vous à la mini debconf Marseille ?


  • Logilab à Pas Sage en Seine 2018 #PSES2018

    2018/07/13 by Arthur Lutz

    Nous étions présents à la conférence Pas Sage en Seine 2018 pour assister aux conférences, mais aussi pour participer à la tenue du stand de l'APRIL dont Logilab est adhérente depuis sa création pour soutenir la promotion et la défense du logiciel libre.

    Voici un court retour sous forme de notes sur les conférences auxquelles nous avons assistées et qui sont en lien avec notre activité.

    Le programme était chargé, retrouvez le sur https://programme.passageenseine.fr/

    Conf zero knowledge webapp

    M4Dz de AlwaysData a effectué avec brio cette présentation.

    Article wikipedia sur Zero Knowledge Proof

    Dans le navigateur, certains acronymes sont familiers, d'autres un peu moins :

    • CORS
    • CSP
    • SRI - protection (signature de code)
    • Referrer-Policy
    • Key-storage (WebCrypto, File-API), éviter LocalStorage (peut être purgé comme du cache)

    WebAssembly (ASMjs) - prévient la lecture du code executé et rend l'extraction de données complexe. Plus difficile d'exploiter un binaire que un bout de JS où on peut se brancher où on veut (ralentir les attaques).

    Pendant les questions/réponses il a été question de "chiffrement homomorphique" comme potentielle solution pour les questions d'indexations de contenus chiffrés.

    Applications où y des choses similaires, dont certaines que nous utilisons à Logilab :

    Full-remote : guide de survie en environnement distant

    Encore une fois M4Dz de AlwaysData.

    Beaucoup de contenu, mais j'ai bien aimé les notions suivantes :

    • mentorat
    • mini-projet interne pour débuter - pour aller discuter avec les anciens
    • manifesto : exemple http://remoteonly.org (auquel on peut apporter quelques critiques)
    • exemple de remote le matin, pour ensuite être dans les bureaux l'après-midi
    • environnement sonore (à personnaliser)

    Pas mal de propos sur les canaux de communication:

    • tchat / voice / video / documents
    • exemple de github qui a enlevé le mail de ses outils de communication
    • virtualopenspace, notamment pour pause café (voir notre inspiration peopledoc et gitlab)
    • abuser des status type jabber/xmpp - pour communiquer sur notre disponibilité (notamment quand on a besoin d'être concentré et pas interrompu)

    Le temps de trajet peut être utile pour décompreser ou se mettre en condition pour travailler. Selon M4Dz, c'est reproductible en teletravail (aller faire un tour du quartier).

    Exemples de rencontres informelles entre télétravailleurs : nextcloud a une équipe très distribuée, ils vont travailler chez les uns les autres (ceux qui ont des affinités entre eux).

    À voir absolument si votre entreprise a une reflexion sur le télétravail, même en partiel (comme c'est le cas à Logilab).

    Jour 2

    Privacy by design

    Notes :

    • GRDP check list
    • déléger l'authentification à l'autres par exemple : openid
    • libjs : jwcrypto, jsencrypt, js-nacl (lien dans les slides pour la liste complète)
    • séparer les consentements (par service tiers)
    • exemple de nextcloud qui fait bien les choses https://nextcloud.com/privacy/
    • matomo (ex-piwik) fait bien les choses en terme de respect de vie privée
    • documentation des api (swagger et apiary pour supprimer les données

    Sur la pseudonimiation (pour publier des jeux de données), M4Dz nous a parlé de Differential privacy

    Crypto quantique

    Comment commencer à tester la crypto quantique en pratique :

    Conclusion, il est urgent d'attendre, on a plein d'autres problèmes de securité à résoudre.

    GRPDBookClub

    Super retour d'experience sur comment aborder un texte de loi ou une reglementation compliquée de manière collective.

    La RGPD pour les noobs

    Excellent complément de la conférence précédente sur le RGPD.

    Fin

    Voilà. Plein d'autres conférences méritent d'être visionnées sur https://video.passageenseine.fr/ (peertube, what else?), bravo pour la captation, la diffusion en direct et la mise à disposition des contenus.

    Bravo à tout l'équipe d'organisation pour les contenus riches et variés de cette édition du festival. Et merci à toutes les personnes avec qui j'ai pu échanger en marge des conférences

    Si vous êtes arrivés jusqu'ici, déjà bravo, et puis sachez que Logilab recrute, rejoignez nous pour travailler sur ces questions.

    Logilab recrute!


  • Meetup Nantes Monitoring - janvier 2018 - netdata & sensu

    2018/01/31 by Arthur Lutz

    En janvier, j'ai fait une présentation interactive sur :

    Le tout en mode "on monte une infra en live/atelier"...

    Les diapos de la présentation sont sur : http://slides.logilab.fr/2018/meetup_monitoring_sensu_netdata.pdf

    https://www.logilab.org/file/10127892/raw/Screenshot%20from%202018-01-31%2009-45-04.png

    Pour les prochaines rencontres, inscrivez vous sur la page du meetup


  • Mon 2ème Hackathon BnF

    2017/11/30 by Adrien Di Mascio

    Et de 2 !

    La semaine reprend tranquillement après ma participation au 2ème hackathon organisé par la BnF. Tout comme pour le premier, il faut tout d'abord saluer une organisation exemplaire de la BnF et la grande disponibilité de ses membres représentés par l'équipe jaune pour aider l'équipe rouge des participants. Quelqu'un a fait une allusion à une célèbre émission de télévision où le dernier survivant gagne… je ne sais pas dans notre cas si c'est un rouge ou un jaune.

    Lors de ce hackathon, j'ai eu le plaisir de retrouver certains de mes coéquipiers de l'an dernier et même si nous étions cette année sur des projets différents, je leur ai donné un petit coup de main sur des requêtes SPARQL dans data.bnf.fr. Peut-être que je pourrai demander un T-shirt mi-jaune mi-rouge l'an prochain ?

    Pour ma part, j'ai intégré, avec une personne des Archives Nationales, une équipe pré-existante (des personnes de la société PMB et de Radio-France qui travaillent déjà ensemble dans le cadre du projet doremus) qui avait envisagé le projet suivant : partir d'une programmation de concert à la Philharmonie de Paris ou Radio-France et découvrir l'environnement des œuvres musicales qui y sont jouées. Pour y aboutir, nous avons choisi de :

    • récupérer la programmation des concerts depuis doremus,
    • récupérer les liens des œuvres de ce concert vers les notices de la BnF lorsqu'ils existent,
    • récupérer des informations sur data.bnf.fr (date de création, style, compositeur, chorégraphe, etc.)
    • récupérer des extraits sonores de Gallica en utilisant l'API SRU,
    • récupérer les extraits des journaux de Gallica qui parlent de l'œuvre en question au moment de sa création,
    • récupérer des informations de wikipedia et IMSLP en utilisant les alignements fournis par data.bnf.fr,
    • récupérer un extrait sonore et une jaquette de CD en utilisant l'API de Deezer à partir des EAN ou des codes ISRC récupérés de data.bnf.fr ou des alignements sur MusicBrainz

    Finalement, rien de trop compliqué pour que ça rentre dans un hackathon de 24h mais comme l'an dernier, tout est allé très vite entre les différents points d'étape devant le jury, les requêtes qui ne marchent pas comme on voudrait, la fatigue et la difficulté à bien répartir le travail entre tous les membres de l'équipe…

    Félicitations à MusiViz qui a remporté l'adhésion du jury ! Je suis pour ma part très heureux des échanges que j'ai eus avec mes coéquipiers et du résultat auquel nous avons abouti. Nous avons plein d'idées pour continuer le projet dont le code se trouve désormais sur http://framagit.org/adimascio/auconcert et un démonstrateur temporaire ici.

    Yapuka continuer…

  • Linkdump suite au Meetup Docker Nantes sur OpenShift

    2017/06/28 by Arthur Lutz

    La Poste nous a fait un retour d’expérience sur la mise en place et l'adoption de OpenShift ainsi que les pratiques associées.

    Affiche Docker Meetup - OpenShift

    À défaut de faire un compte rendu, voici (en vrac) quelques liens collectés pendant la présentation :

    Merci aux organisateurs et à Guillaume et Pascal pour leur présentation. Merci à Epitech pour l’accueil, et Seyos et Zenika pour le moment de convivialité après la présentation.


  • Logilab présent à pgDay Toulouse

    2017/06/16 by Philippe Pepiot

    Le 8 juin 2017 nous avons assisté à pgDay, le moment de rencontre et de conférences de la communauté PostgreSQL francophone, qui s'est déroulée au campus de Météo France à Toulouse.

    https://www.logilab.org/file/10126216/raw/logo_pgfr_sans_900_400x400.png

    Partitionement

    Gilles Darold nous a fait un tour d'horizon des solutions de partitionnement, de la méthode manuelle avec des triggers et d'héritage de table en passant par l'extension pg_partman jusqu'au partitionnement déclaratif de la future version 10 avec la syntaxe PARTITION OF

    Le partitionnement permet de gérer plus facilement la maintenance et les performances de tables avec beaucoup d'enregistrements.

    Transaction autonomes

    Le même Gilles Darold nous a parlé des transactions autonomes c'est-à-dire des transactions qui s'exécutent dans une transaction parente et qui peut être validée ou annulée indépendamment de celle-ci, ce qui peut être utile pour enregistrer des événements.

    PostgreSQL buffers

    Vik Fearing nous a expliqué le fonctionnement et l'interaction des différents tampons mémoire dans PostgreSQL.

    Les pages sont chargées du disque vers les shared_buffers, qui sont partagés par toutes les connexions, et ont un usageCount entre un et cinq qui est incrémenté à chaque fois qu'elle est accédée. Lorsqu'une nouvelle page doit être chargée, un mécanisme de clock-sweep boucle sur le cache et décrémente l'usageCount et quand il vaut zéro la page est remplacée par la nouvelle. Ainsi pour une page avec un usageCount à cinq, il faudra au moins cinq tours des shared_buffers par le clock-sweep avant quelle ne soit remplacée.

    En cas d'un accès à une grosse table pour ne pas vider tout le cache, PostgreSQL utilise un tampon circulaire (ou ring buffer) limité en taille pour cette table.

    Les tables temporaires utilisent un tampon dédié, le temp_buffers.

    Quand une page est modifiée, elle l'est d'abord dans les wal buffers qui sont écrits sur disque lors du commit par le processus wal writer.

    Le writer process parcoure les shared_buffers tout les bgwriter_delay (200ms) et écrit sur disque un certain nombre de pages qui ont été modifiées, ce nombre est contrôlé par les paramètres bgwriter_lru_maxpages et bgwriter_lru_multiplier.

    Des checkpoint s'exécutent aussi tout les checkpoint_timeout ou plus fréquemment quand la taille des wals dépasse la valeur du paramètre max_wal_size. Lors d'un checkpoint on cherche des pages à écrire (ou dirty pages) et on les trie pour éviter les écritures aléatoires sur le disque. Le paramètre checkpoint_completion_target permet d'étaler la vitesse d'écriture entre deux checkpoint. Idéalement on veut qu'ils se déclenchent toujours par timeout et que l'écriture soit la plus étalée pour avoir des performances de lecture et d'écriture constantes.

    Pour déboguer l'utilisation des buffers et les I/O disques il y a la table pg_stat_bgwriter, l'extension pg_buffercache, et le paramètre track_io_timing à utiliser avec EXPLAIN (ANALYZE, BUFFERS).

    Les pires pratiques PostgreSQL

    Thomas Reiss et Philippe Beaudoin nous ont présenté quelques unes des plus mauvaises pratiques avec PostgreSQL, notamment de celle répandue du manque ou d'excès d'index. À ce sujet Dalibo a développé l'outil PoWA qui analyse l'activité d'une base et fait des suggestions d'index. Attention aussi à la tentation de (trop) destructurer les données, PostgreSQL possède de nombreux types qui offrent une garantie forte sur la consistance des données et de nombreuses opérations dessus, par exemple les types ranges.

    La communauté des développeurs de PostgreSQL

    Daniel Vérité nous a fait un historique de Ingres puis Postgres, et enfin PostgreSQL avant de nous montrer des statistiques sur les commits et la liste de diffusion utilisée pour le développement de PostgreSQL

    Les éléphants mangent-ils des cubes ?

    Cédric Villemain nous a parlé des fonctionnalités de PostgreSQL pour des requêtes de type OLAP. L'implémentation de TABLESAMPLE qui permet de faire des requêtes sur un échantillon aléatoire d'une table. Le paramètre default_statistic_target et la nouvelle commande de la version 10 CREATE STATISTICS qui permettent d'obtenir de meilleurs statistiques sur la distribution de la table et donc d'avoir de meilleurs plans d'exécution.

    Aussi depuis la version 9.4, la syntaxe GROUP BY ROLLUP permet de faire des agrégats sur plusieurs GROUP BY dans une seule requête. Auparavant il fallait faire plusieurs UNION pour obtenir le même résultat.

    À noter aussi l'utilisation d'index BRIN et BLOOM.

    Comment fonctionne la recherche plein texte ?

    Adrien Nayrat nous a présenté les fonctions de recherche plein texte dans PostgreSQL et le moyen de l'améliorer en créant ses propres configurations et dictionnaires de mots, ainsi qu'à la rendre plus performante avec les index GIN et GIST.

    GeoDataScience

    Olivier Courtin nous a montré avec un exemple concret comment PostgreSQL pouvait être un environnement idéal pour la géomatique et le machine learning avec les extensions PostGIS, ainsi que plpythonu utilisé pour exécuter du code python directement sur le serveur PostgreSQL. L'extension dédiée crankshaft propose des API basées sur scipy et scikit-learn et peut être appelée via des procédures SQL.

    https://www.logilab.org/file/10126217/raw/freefall.gif

  • Compte rendu Nantes Monitoring mai 2017

    2017/05/11 by Arthur Lutz

    Voici un compte rendu du Meetup Nantes Monitoring de mai 2017

    Présente ta stack

    Léo / Matlo

    Léo de Matlo nous a présenté son utilisation de prometheus https://prometheus.io/ . Matlo a commencé à migrer vers une solution SASS (monitoring as a service) chez https://bleemeo.com/ (entreprise Toulousaine). La stack de bleemeo est décrite sur stackshare: https://stackshare.io/bleemeo/bleemeo. L'agent de bleemeo est publié en logiciel libre https://github.com/bleemeo/bleemeo-agent et repose sur telegraf https://github.com/influxdata/telegraf . Bleemeo semble utiliser MQTT-SSL pour remonter les métriques permettant ainsi un usage raisonnable des connexions réseau (cf diagramme https://bleemeo.com/features/).

    https://bleemeo.com/images/bleemeo_agent.png

    Emeric / OasisWork

    Emeric de OasisWork nous a présenté leur utilisation de sensu https://sensuapp.org/ qui permet d'avoir une architecture en mode "push". La configuration se fait par "rôles" coté serveur, simplifiant la configuration des agents. Des plugins sont utilisables pour les checks https://sensuapp.org/plugins et Oasiswork a contribué à ces plugins (https://github.com/oasiswork/sensu-community-plugins/) et en a écrit en python (habituellement c'est en ruby principalement). Sensu a la particularité d'utiliser dans son architecture RabbitMQ pour le transport https://sensuapp.org/docs/latest/overview/architecture.html. Pour la visualisation l'interface web libre de sensu est utilisée : uchiwa.

    https://uchiwa.io/img/browser.png

    Arthur / Logilab

    J'ai fait un bref exposé de nos briques de supervision/monitoring à Logilab. Du munin, du shinken, du statsd, graphite, graphite events, grafana, et en particulier la génération de ces configuration (coté serveur et client) par Saltstack. Nous utilisons aussi salt pour remonter des métriques en utilisant son bus de communication zmq à l'échelle de notre infrastructure, permettant par conséquent de re-développer des équivalents de smokeping et weathermap avec salt, carbon, graphite et grafana. Pour plus de détails sur ce type d'architecture voir les épisodes précédents (, ici, et aussi, et là).

    https://www.logilab.org/file/10125980/raw/architecture.png

    Quels outils choisir pour son monitoring ?

    Exercice difficile, nous avons listé les produits connus par les participants puis un certain nombres de critères de choix, et puis nous avons rempli (partiellement) un tableau en discutant de chaque point.

    Produits

    • nagios
    • shinken
    • icinga
    • sensu
    • prometheus
    • ELK
    • packet beats
    • file beats
    • zabbix
    • centreon
    • check-mk
    • ganglia
    • statsd
    • graphite
    • influxdb
    • telegraf
    • cadvisor
    • graylog
    • rsyslog
    • splunk
    • thruk
    • collectd
    • metrics(java)
    • logentries
    • datadog
    • bleemeo
    • prtg
    • munin
    • smokeping
    • fluentd
    • dynatrace
    • OMD

    (liste non-exhaustive, forcément... )

    Critères

    • language
    • prix
    • age
    • maintenu
    • communauté
    • scalable
    • facilité de mise en place (pkgs, devops, etc.)
    • champs d'application
    • push / pull architecture
    • configuration - format
    • configuration - serveur/agent
    • open core
    • securité
    • IOT ready
    • modularité / plugins
    • interface utilisateur (UX, interface web, etc.)
    • alertes
    • developpement de sondes

    Début de tableau

    Bien evidemment, nous n'avons pas rempli la totalité du tableau, mais les échanges ont été riches d'enseignements. Voici un apercu (flou) du tableau élaboré collectivement.

    https://www.logilab.org/file/10125977/raw/2017-05-09%2021.16.15.jpg

    Fin

    En fin de meetup nous avons parlé des conférences devoxx publiés récemment https://www.youtube.com/channel/UCsVPQfo5RZErDL41LoWvk0A et des contenus sur le monitoring et l'aggrégation de logs, notamment le projet cerebro de voyage-sncf : https://github.com/voyages-sncf-technologies/cerebro


  • "Gestion d'entrepôts et de paquets Debian non officiels" aux rencontres Debian Nantes

    2017/02/09 by Arthur Lutz

    Cet article résume le retour d'expérience d'Arthur Lutz (Logilab) sur la gestion d'entrepôts et de paquets Debian non officiels présenté lors des rencontres Debian Nantes en février 2017. Il a été complété en direct-live par Cyril Brulebois.

    https://www.logilab.org/file/2269692/raw/debian_nantes.png

    Objectifs

    • distribuer du logiciel qu'il n'est pas nécessaire de faire rentrer dans Debian
    • livrer ses clients (via https protégé par mot de passe)
    • préparer des backports
    • changer des options de compilation
    • activer des modules/plugins
    • compiler pour une version précise de debian (type wheezy-backports construit sur jessie)
    • diminuer les opérations manuelles
    • flexibilité de l'automatisation (pouvoir passer en manuel à tout moment, rejouer une étape, etc.)
    • progressivement corriger les erreurs signalées par lintian

    Récuperer les sources et le packaging

    • dget
    • debcheckout (utilise VCS-, bzr, git, etc.)
    • apt-get source

    Construire sur place

    • dpkg-buildpackage
    • pdebuild (wrapper pour les suivants)
    • pbuilder (dans un chroot)
    • sbuild (official) sur buildd
    • cowbuilder
    • logilab-packaging (lgp)

    Gestion des dépôts

    Entrepôts d'autres technologies

    Futur


  • Mon Hackathon à la BnF

    2016/11/24 by Adrien Di Mascio

    J'ai eu la chance de participer au premier hackathon BnF qui s'est déroulé les samedi 19 et dimanche 20 novembre. Alors, c'est quoi un hackathon BnF ?

    C'est d'abord un lieu ! Un lieu insiprant qui a été ma deuxième maison mon deuxième lieu de travail pendant ces 5 dernières années où j'ai travaillé sur data.bnf.fr.

    https://upload.wikimedia.org/wikipedia/commons/thumb/0/0b/BNF_FM_Hall_Est.jpg/512px-BNF_FM_Hall_Est.jpg

    Et puis une thématique : mettre en avant le patrimoine de la BnF et inventer de nouveaux usages numériques autour de ses ressources. Pas beaucoup de contraintes si ce n'est de rendre le code disponible sous une licence libre.

    Je ne connais pas bien toutes les applications de la BnF et en particulier je ne maîtrise pas tous les services de Gallica (honte à moi !) mais je commence à avoir une certaine idée de ce que sont les données à la BnF, de comment elles sont rangées (je finis même par connaître les zones intermarc et pouvoir comprendre des 100$blagues). Au-delà du projet data.bnf.fr lui-même, la connaissance de ces données, de leur récupération et de leur usage s'est affinée avec mes travaux sur les projets OpenCat, reliures, bp16, et tous les autres passés ou en cours où on a relié des bases de données extérieures aux notices d'autorité de la BnF comme human-music , andrebreton, les registres de la Comédie-Française, libretheatre, prototype biblissima, bientôt des morceaux d'Archives départementales et nationales et j'en oublie certainement. Je partais donc avec l'idée qu'à défaut de réaliser quelque chose, je saurai a minima servir de facilitateur dans la récupération et le traitement des données.

    Le hackathon, c'est aussi une ambiance conviviale portée par les quelques 70 participants qui sont venus, la dizaine d'équipes ainsi constituées et tous les agents BnF qui se sont relayés pendant plus de 24h pour répondre à nos questions, nous guider ou redonner un petit coup de boost lorsque la fatigue ou la frustration commençaient à gagner du terrain. Oui parce qu'en fait, on était quand même là pour tenter de produire quelque chose… Pour ma part, j'ai rejoint en début de hackathon le projet porté par Carmen Brando et Francesca Frontini dont le but était de pouvoir extraire de Gallica les tables des matières et les textes OCRisés et procéder à de la reconnaissance d'entités nommées. Plus précisément, il s'agissait de pouvoir retrouver les lieux et personnes cités dans les textes numérisés pour les aligner vers les données de data.bnf.fr. À la différence d'autres projets, nous voulions donc créer de la nouvelle donnée et l'exploiter plutôt que de réutiliser des relations ou indexations déjà présentes dans les catalogues. Si ce chantier aboutissait, les intérêts pourraient être multiples puisqu'on pourrait imaginer une navigation enrichie de cartes ou de nouveaux rebonds, de nouvelles visualisations à partir de statistiques et possiblement soulever de nouvelles questions de recherche sur les textes eux-mêmes.

    Relations entre auteurs / visualisation créée par Marine Riguet

    Relations entre auteurs / visualisation créée par Marine Riguet

    Nous nous sommes plus ou moins répartis en sous-groupes de travail (je simplifie car chacun a en réalité participé de près ou de loin à tout) :

    • Paule, Delphine et Marc qui étaient nos experts littéraires et nous ont aidé à déterminer des corpus de travail pertinents pour tester nos outils,
    • Frédéric, qui avait développé l'outil de traitement linguistique Alix, et qui s'est donc occupé du traitement initial et des annotations linguistiques des textes,
    • Carmen et Francesca, qui avaient écrit le moteur de reconnaissance d'entités nommées REDEN, se sont occupées d'améliorer l'outil pour permettre le traitement du texte annoté et retrouver les concepts databnf et dbpedia de personnes et de lieux,
    • Gaétan, Mehdi (issus de l'équipe Prevu), Jean-Baptiste se sont plus concentrés sur le développement d'une appli JS pour naviguer et visualiser les résultats obtenus,
    • Bruno et moi-même voguions de sous-groupe en sous-groupe pour faciliter la récupération de données, réaliser les divers pré/post-traitements et aussi taper un peu sur la visu.

    Le résultat ? Je crois que nous avons été un peu trop ambitieux et il n'est malheureusement pas encore consultable en ligne mais on va tenter d'y travailler dans les jours qui viennent et de rendre le code accessible. Même si ce n'est encore qu'une preuve de concept, on a malgré tout obtenu quelques jolis résultats comme l'affichage d'une carte des lieux mentionnés dans une œuvre avec rebonds interactifs vers les pages correspondantes dans Gallica ou encore des pages de statistiques sur les personnes citées. Tout ça est encore loin d'être industrialisé et il y a évidemment plein de problèmes comme la résilience face à un mauvais OCR (on s'est concentrés sur les textes dont la qualité d'OCRisation était supérieure à 80% d'après Gallica), à l'ancien français ou encore à la gestion propre des personnes ou lieux fictifs vs. réels.

    Exemple d'écran de navigation obtenu qui fait le lien entre une carte et un texte OCRisé de Gallica

    En tout cas, j'ai eu la chance de tomber sur des co-équipiers de luxe et je garderai un excellent souvenir de ces 24h. Pour conclure, j'adresse un grand bravo à gallicarte qui a remporté le prix du jury et à diderotbot qui a trouvé de belles perles dans Gallica qui résonnaient particulièrement bien avec l'actualité.

    À l'année prochaine pour la suite j'espère !


  • Le forum ouvert

    2016/11/23 by Sylvain Thenault

    J'ai eu l'occasion de participer une nouvelle fois à un forum ouvert lors de la rencontre autour de l'entreprise libérée organisée par l'APAP et NOÏO (la dernière, c'était à l'Agile Tour Toulouse) . J'en ai fait un petit compte-rendu mais ce n'est pas l'objet de ce billet.

    Comme je trouve que le forum ouvert est vraiment un format super pour tirer le meilleur parti d'un groupe de gens indépendamment de la taille du groupe, je vais ici faire un petit rappel des bases (telles qu'elles nous ont été rappellées lors de cette rencontre), qu'on peut ensuite adapter en fonction de ses propres contraintes.

    Les principes du forum ouvert (ou Open Space) sont inspirés du fait que dans les conférences, la plupart des choses intéressantes sont dites en off : en discutant entre les conférences, pendant le café, devant la porte, etc. L'idée est donc de transformer la conférence en une grande pause avec des discussions libres, en petit groupe, autour d'un thème donné et avec les quatre principes suivants pour mettre tout le monde à l'aise :

    • toutes les personnes présentes sont les bonnes personnes,
    • ce qui arrive est ce qui pouvait arriver,
    • quelque soit le moment où ça commence, c'est le bon moment,
    • et quand c'est fini, c'est fini.
    https://www.logilab.org/file/9306538/raw/20161121_194647.jpg

    Partant de ces bases, un forum ouvert se déroule en quatre phases :

    1. introduction du sujet et des principes du forum ouvert énoncés ici,
    2. proposition et éventuellement sélection des sujets,
    3. plusieurs rounds de discussions sur les sujets choisis,
    4. choix d'actions et clôture.

    Une fois le sujet introduit, voici le détail du déroulement des étapes suivantes...

    L'émergence des sujets

    Dans cette première phase, chacun est invité à proposer un sujet qu'il va écrire en gros sur une feuille en y indiquant également son nom. Cette feuille sera affichée sur un tableau qu'on nomme la place du marché, accompagnée d'une indication de l'heure et du lieu où aura lieu cette discussion.

    Pour cette indication, l'organisateur aura au préalable préparé une grille d'emploi du temps déduite :

    • du nombre de discussions en parallèle (en fonction de l'espace ou des tables disponibles ainsi que du nombre de personnes présentes - compter entre 5 et 10 personnes max par groupe),
    • de la durée et le nombre de créneaux successifs (au moins 40 minutes pour un créneau, le temps passe vite !).

    À partir de ces informations on obtient une grille horaire dans laquelle les propositions pourront être placées, ainsi accompagnée d'un lieu (en général un numéro de table) et d'un créneau horaire.

    https://www.logilab.org/file/9306522/raw/20161121_194729.jpg

    On peut apparemment tabler sur une proposition de sujet pour deux personnes en moyenne. Si plusieurs propositions sont similaires, il est possible de les recouper si les porteurs du sujet le souhaitent. Enfin s'il est nécessaire de faire une sélection, on peut demander aux participants de "s'inscrire" sur les sujets afin de voir lesquels sont les moins suivis.

    Le temps des discussions

    Et c'est parti pour le premier round de discussion ! Chaque porteur de sujet s'installe à sa table, y indique clairement le sujet discuté (on laisse l'affichage général en place pour les retardataires et promeneurs) et attend d'être rejoint par d'autres personnes également intéressées par ce sujet. Il a deux responsabilités :

    • introduire le sujet,
    • s'assurer qu'un compte-rendu sera écrit (mais pas forcément par lui).

    Animer la discussion n'en fait pas parti.

    Pendant les discussions, on peut ajouter :

    • la loi des deux pieds : chacun est libre s'il en ressent l'envie pour une raison ou pour une autre de quitter sa table pour aller s'installer sur une autre,
    • les abeilles qui butinent de tables en tables, sans jamais vraiment s'installer mais en permettant d'essaimer l'information d'une table à l'autre,
    • les papillons qui papillonnent un peu en marge du processus, mais il n'est pas rare d'en voir émerger des choses.
    https://www.logilab.org/file/9306530/raw/20161121_194658.jpg

    Une dizaine de minutes avant la fin du créneau, l'organisateur indique qu'il est temps de s'assurer que le compte-rendu de la discussion sera fait. Enfin à la fin du temps imparti, chaque table va afficher son compte-rendu sur le grand journal.

    https://www.logilab.org/file/9306515/raw/20161121_212456.jpg

    Je trouve qu'il est intéressant de réserver un créneau à ce moment là pour qu'une personne par table présente ce compte-rendu en quelques minutes, car il est parfois difficile de se contenter de ce qui est écrit ou dessiné.

    Après on enchaîne rapidement sur le round suivant, et ainsi de suite.

    La clôture

    À ce moment là, tout le monde commence à être bien détendu, en confiance, et à connaître au moins une partie des participants. Afin de faire avancer la cause discutée, on va effectuer une dernier round de propositions / discussions dont l'objectif est de dégager des actions réalistes à court terme. Sur le modèle des étapes précédente, les participants sont invités à proposer une action qu'ils ont envie de tirer (ou de voir tirer) avec d'autres. Ils l'énoncent et l'affichent sur le marché aux actions.

    Une fois toutes les actions proposées, les personnes intéressées par une action donnée se regroupent et structurent une action qui sera énoncée devant l'assistance une fois le temps imparti écoulé. Si possible, l'organisateur effectuera un suivi de ces actions après l'évènement.

    https://www.logilab.org/file/9306297/raw/20161121_214833.jpg

    Il est ensuite temps de se féliciter, de se remercier, d'annoncer la suite ou toute autre chose utile avant de se quitter.

    Les photos sont tirées de l'évènement sus-cité, merci aux organisateurs et en particulier ici aux facilitateurs graphiques !


  • Rencontre autour de l'entreprise libérée à Toulouse

    2016/11/23 by Sylvain Thenault

    J'ai eu l'occasion de participer à une rencontre autour de l'entreprise libérée organisée par l'APAP et NOÏO sur Toulouse. Voici quelques notes pour la postérité.

    https://www.logilab.org/file/9306297/raw/20161121_214833.jpg

    La première partie de cette rencontre était la diffusion du documentaire E 3.0, Une entreprise humaniste qui présente les 6 premiers mois de la "libération" d'Averia, une entreprise de miroiterie d'ile de france. Le réalisateur était présent et nous a annoncé en amont de la projection son parti pris volontaire pour l'entreprise libérée (ce qui n'est pas pour me déplaire). J'ai trouvé ce documentaire intéressant de par l'aspect "témoignage sur le vif" et par le suivi sur quelques mois de cette phase critique de transformation. Ça donne envie de savoir où il en sont maintenant (la période filmée est le second semestre 2015).

    La seconde partie s'est déroulée sous la forme d'un forum ouvert. Au delà des sujets de départ que j'avais choisi, cela m'a surtout permis d'échanger avec d'autres personnes dont l'entreprise est plus ou moins avancée sur le chemin de la libération (j'ai du mal avec ce terme que je trouve un peu galvaudé mais bon). J'y ai notamment rencontré une dirigeante d'une société de pose de parquets (Erah), en voie de "libération" depuis 5 ans. Celle-ci a pour le moins étonné tout le monde lorsqu'elle nous a appris que ses salariés avaient décidés ensemble d'être tous payés pareils, indépendamment de leur expérience (mais légèrement au dessus des prix du marché même pour les expérimentés), ou encore que la société finançait à ses salariés des stages sur leur temps de travail, indépendamment de l'intérêt du sujet pour elle. J'ai également discuté avec la dirigeante de Fun and fly qui gère son entreprise d'une dizaine de personnes dans la veine de l'entreprise libérée sans le savoir jusqu'ici. Non sans similitude avec Logilab, où nous avons grandi depuis 2000 avec bon nombre de principes aujourd'hui regroupés sous la bannière de l'entreprise libérée.

    https://www.logilab.org/file/9306355/raw/20161121_222142.jpg

    La soirée s'est conclut pour moi avec le directeur de Web-Atrio qui devrait prochainement inviter le petit groupe que nous avons formé à un déjeuner ou diner afin d'aller plus loin dans les échanges autour de nos avancées et expérimentations respectives, élément qui est apparu essentiel à chacun, même si nous n'espérons pas y trouver de recettes miracles s'appliquant à tout le monde.

    Pour aller plus loin, le lecteur intéressé pourra :

    • regarder cette conférence d'Isaac Getz qui m'a été recommandée pendant la soirée (à Logilab Toulouse nous en avons regardé une de Frédéric Laloux que je recommende également si vous n'avez pas lu son livre),
    • lire une bande dessinée à ce sujet,
    • suivre ce qu'il se passe du côté de l'association MOM21, qui devrait notamment créer une antenne Sud-Ouest et organiser une journée à ce sujet le 18 janvier prochain (mais je n'ai pas trouvé plus d'info à ce sujet sur leur site).

    Merci à tous les organisateurs pour ce moment rondement mené et qui a permis de se rendre compte qu'on n'est pas seul sur le chemin !


  • Linkdump du meetup docker Nantes septembre 2016

    2016/10/04 by Arthur Lutz

    La semaine dernière, je suis allé au meetup docker sur "Containers' Jungle. Docker, Rocket, RunC, LXD ... WTF ?".

    À Logilab, nous sommes parfois un poil déçus par docker (mais utilisateurs comme vous pouvez le voir sur notre blog Developing salt formulas with docker, Running a local salt-master to orchestrate docker containers, Building Docker containers using Salt, Retour sur la journée conteneurs dans le cadre de Open Source Innovation Spring). Du coup nous étions curieux d'aller creuser la piste de rocket et autres technologies de conteneurs.

    https://www.logilab.org/file/8445845/raw/global_361217852.jpeg

    Nicolas De Loof nous a présentés quelques concepts sous-jacents à docker, mais aussi quelques alternatives et retours d’expérience sur l'utilisateur de docker et de son écosystème. La présentation sera rejouée au devfest Nantes pour ceux qui l'auraient ratée.

    Voici quelques liens collectés lors du meetup qui nécessiteraient un peu plus de lecture et d'explications, mais je pose cela tel quel au cas où ce serait utile à d'autres :

    Un meetup recommandé pour explorer docker (et ses alternatives?) à Nantes.


  • Nantes Monitoring Meetup - Septembre 2016 - Heka & Hindsight

    2016/09/14 by Arthur Lutz

    Hier soir, j'étais au Nantes Monitoring Meetup, Mathieu Parent (aussi développeur debian) nous a présenté l'utilisation de heka et hindsight à Nantes Metropole. Beaucoup de contenu et de principes, voici quelques liens que j'ai collecté pendant la présentation.

    Diagramme d'architecture de l'utilisation de heka chez Mozilla (en 2015)

    http://people.mozilla.org/~rmiller/heka-monitorama-2015-06/moz-pipeline.png

    Le prochain meetup aura lieu de mardi 8 novembre, rejoignez nous sur meetup.


  • Agile France 2016

    2016/06/30 by Marla Da Silva

    Nous avons assisté à la conférence Agile France qui a eu lieu les 16 et 17 juin au Chalet de la Porte Jaune, à Paris.

    La grande conférence agile francophone, de la communauté pour la communauté, réalisée dans un lieu exceptionnel proposait d'aborder différents sujets, tels que les méthodes agiles, l'intelligence collective et la facilitation, le développement de logiciels, l'expérience utilisateur d'innovation, les organisations et leur management, etc.

    Dans un cadre très agréable permettant de s'échapper de l'ambiance urbaine, notre équipe a pu assister à quelques conférences qui ont attirées notre attention :

    Facilitation graphique

    Jean-Pierre Bonnafous, qui a participé aux 15 ans de Logilab, a invité les participants à réagir tout au long de ces deux jours et a mis en image leurs retours.

    https://www.logilab.org/file/6729471/raw

    Toutes les sessions d'Agile France étaient présentées sur une fresque. Nous, nous sommes fans !

    https://www.logilab.org/file/6831358/raw

    Utilisateur, fais moi mal : la ditacture du test

    Emilie-Anne Gerch et Nicolas Moreau ont parlé de l'importance du test utilisateur d'une façon dynamique et ont partagé leur expérience concernant le site d'AXA Assurances avec une approche assez drôle : les designers viennent de Vénus et les développeurs de Mars, les utilisateurs sont, quant à eux, de bons Terriens. Comment ramener sur Terre un designer un peu trop perché ou sortir de sa grotte un développeur pour qui un texte blanc sur fond noir est la norme ?

    Grande leçon pour les designers, les développeurs et les chefs de projet, car ceux qui apportent la bonne réponse ce sont les utilisateurs. Selon eux, c'est le jury le plus juste, car ce sont eux qui utilisent le produit final. Les utilisateurs finaux constituent le jury le plus sévère mais le plus juste qui soit. Ils ont des mots parfois crus et des doigts qui cliquent partout sauf là où on avait pensé. :-)

    Les tests utilisateur permettent de tester un produit en conditions réelles. Grâce à ceux-ci, il est possible de recueillir des informations utiles pour améliorer le produit. Ils permettent de donner une priorité à différentes fonctionnalités ou idées. Ils permettent de reconnaître les fonctionnalités à conserver (les plus utilisées, les plus demandées...) et celles à supprimer (celles que personne ne voit ou n'utilise). Ils constituent aussi un moyen d'intégrer efficacement l'utilisateur dans la conception.

    Quelques points permettant de mieux comprendre la psychologie de l'utilisateur :

    L'être humain utilise rarement un outil pour sa fonction primaire. Il est partisan du moindre effort, il bricole et modifie les outils de manière à les adapter à son besoin.

    L'utilisateur souhaite avant tout aller à l'essentiel.

    Il ne veut pas avoir la sensation de devoir apprendre. Il ne lit pas les manuels, il pioche les informations dont il a besoin lorsque la nécessité se fait sentir.

    Il est influencé par l'extérieur (le bruit, un interlocuteur), par son état émotionnel (le stress, la somnolence...) et par son vécu (il calque ses actions sur ce qu'il a déjà pratiqué ailleurs). Son expérience s'étend au delà du numérique.

    Il est "techno-aveugle" : il veut avant tout que ça marche, la technique utilisée ne l'intéresse pas.

    Il est bienveillant : il aura tendance à se blâmer au lieu de remettre en cause le produit et donne des retours d'expérience très facilement.

    Présentation

    Un iceberg pour explorer ce qui ne va pas

    Certains d'entre-nous ont assisté à la conférence Un iceberg pour explorer ce qui ne va pas, animée par Emmanuel Gaillot et Raphaël Pierquin. La session portait sur la découverte de nos réactions face à un évènement donné.

    Cette conférence a démarré par une démonstration pratique basée sur la métaphore de l'iceberg créée par Virginia Satir. Il arrive qu'on agisse et qu'on réagisse d'une manière qui nous surprend ou nous dépasse. Pendant cette session, nous avons exploré ces situations à l'aide d'un exercice inventé par Virginia Satir, basé sur la métaphore de l'iceberg (ce qui est émergé est observable, ce qui est immergé se passe au-dedans). Les participant·e·s ont pu ainsi s'approprier un format de réflexion simple à suivre pour apprendre à mieux se connaître — et possiblement apprendre à mieux s'apprécier.

    Raphaël Pierquin a choisi un évènement qu'il a contextualisé en décrivant les comportements de chaque personne impliquée dans son récit, puis a présenté sa stratégie par rapport à cet évènement. Guidé par Emmanuel Gaillot, qui avait au préalable disposé des feuilles de papier au sol sur lesquelles étaient écrits les intitulés de chaque "case" de l'iceberg, il a ensuite déroulé devant l'assemblée toutes les étapes présentes sous le niveau de l'eau de l'iceberg. À chaque changement de "case" dans son récit, Raphaël se déplaçait vers la feuille idoine, établissant ainsi son propre cheminement physique et mental. Nous avons ensuite eu l'occasion de pratiquer par trinôme puis de discuter de cette méthode avec Emmanuel et Raphaël.

    https://www.logilab.org/file/6832314/raw

    DDD : et si on reprenait l'histoire par le bon bout ? Tout simplement.

    La conférence sur le DDD (Domain Driven Design), par Thomas Pierrainet Jérémie Grodziski a été une synthèse intéressante sur une approche de conception et de développement permettant de se concentrer sur la valeur métier. Cette approche permet notamment de communiquer efficacement et de collaborer avec les experts métier (qui doivent être capables de lire et comprendre notre code !). Les conférenciers ont su extraire certains principes et patrons de conception du fameux "blue book" à l'origine de cette expression, et les rendre accessibles : les "values objects", la couche anti-corruption, l'architecture hexagonale, etc.

    Forum Ouvert

    À cette occasion plus d'une trentaine d'orateurs ont proposé un sujet qui leur tenait à coeur. Les personnes intéressées pouvaient débattre sur chaque sujet en groupes spontanés répartis dans tout l'espace de la conférence pendant 45 minutes.

    Dans ce type d'activité, les groupes sont petits et donc la répartition du temps de parole est assez homogène.

    Juliette de notre équipe a animé le forum "le bonheur au travail" avec une vingtaine de personnes, elle a pu recueillir beaucoup d'idées intéressantes.

    Voici quelques idées qui se sont dégagées de la reflexion :

    https://www.logilab.org/file/6831796/raw

    Mindfulness & Agile

    Dov Tsal Sela nous a présenté "Comprendre tes équipes, pour comprendre à toi-même". La pleine conscience est l'art de regarder le moment présent avec clarté. En nous conseillant de faire un voyage à travers le Taoïsme, les neurosciences et le royaume animal pour comprendre comment sont prises les décisions personnelles et en groupes (et qui les prend…)

    Au cours de cet atelier, nous avons pu visionner des vidéos, et même méditer un peu.

    Comment j'ai recruté mon pair ?

    Juliette a assisté à une conférence animée par Houssam Fakih et Jonathan Salmona centrée sur le recrutement. Partant du principe que les profils trop semblables feront les mêmes erreurs et souhaitant recruter les bonnes personnes pour leur société, ils ont développé leur propre méthode d'évaluation. L'entretien est, pour eux, une des nombreuses vitrines de l'entreprise, aussi souhaitent-ils que cette expérience se déroule de la manière la plus professionnelle possible. Ils ont établi un modèle d'entretien, ce qui assure l'équitabilité des chances pour tous les candidats. Ils ont présenté leur grille d'évaluation, les différentes difficultés rencontrées, les pièges à éviter, les retours de leurs candidats, le suivi des nouvelles recrues ...

    Mais aussi...

    Laura a participé à une discussion intéressante sur le travail agile réparti sur plusieurs sites. De nombreux participants ont fait des retours sur leur expérience, qui parfois impliquait une équipe de développement répartie dans plusieurs pays. À la distance peuvent donc s'ajouter des difficultés liées aux différences culturelles. En laissant de côté ce dernier aspect qui nous concerne moins à Logilab, plusieurs éléments sont applicables sur nos développements répartis entre Paris et Toulouse :

    Des obstacles à garder en tête :

    Il est difficile de capter le ressenti à distance.

    À distance, on ne bénéficie pas de l'"info café" : ces conversations informelles dans le couloir ou la salle café, qui souvent contiennent des informations utiles pour le projet en cours.

    Certaines pratiques sont plus compliquées à distance : rétrospective, planning poker... Mais il existe des applications en ligne pour ça.

    Il est important de :

    Se rencontrer régulièrement, pour partager la même vision et souder les équipes.

    En début de projet, se mettre d'accord sur un "contrat de développement", avec entre autres les bonnes pratiques et le processus de revue et d'intégration.

    Que tout le monde ait accès à la même information : idéalement, le product owner devrait être sur un troisième site distant, pour ne "favoriser" personne. Si il n'y a pas de PO, faire en sorte que des développeurs de chaque site puissent assister régulièrement aux réunions client.

    Et enfin, pourquoi pas...

    Mettre des webcams en salle de pause.

    Faire du pair-programming réparti.


  • Nous recrutons !

    2016/06/29 by Marla Da Silva

    Vous êtes passionné(e) d'informatique et souhaitez comprendre et maîtriser le fonctionnement de toute la pile applicative, de la base de données à la feuille de style, pour concevoir et développer des produits avec agilité ?

    Nous aussi !

    https://www.logilab.org/file/6817931/raw

    Consultez notre offre "CDI - développement web (client)" et postulez chez nous !


  • J'étais au raid agile #5 !

    2016/05/10 by Laura Médioni
    https://www.logilab.org/file/5920040/raw/gite.jpeg

    J'ai à mon tour eu l'opportunité de participer au raid agile #5 organisé par Pablo Pernot et Claude Aubry dans les Cévennes le mois dernier, et j'en suis revenue ravie. Ces quelques jours en immersion dans un cadre magnifique permettent de se déconnecter du quotidien pour se concentrer pleinement sur l'agilité, le tout dans une ambiance chaleureuse. La formation est dense, mais elle est orientée pratique, prévoit des pauses et fait la part belle aux échanges, conseils et retours d'expérience, ce qui fait qu'on ne voit pas le temps passer. J'y ai appris beaucoup de choses, principalement sur des outils de définition d'un produit que nous utilisons peu (pas assez ?) chez Logilab.

    J'ai donc apprécié tout particulièrement les ateliers sur la définition des parties prenantes, des personas (et dans la même idée, je vais me renseigner sur l'empathy mapping). J'ai également pu découvrir l'impact mapping, le petit plus étant de le précéder d'une étude d'impacts rétro-futuriste, qui permet d'identifier les vrais besoins : on se projette dans un futur où le produit connaît un succès total, en se mettant dans la peau de la ou des persona(s) principale(s). On se "souvient" des raisons (orientées comportement) qui font qu'on ne pourrait plus se passer du produit: les impacts.

    En mars 2015, Sylvain Thénault était revenu du raid agile avec ces réflexions. Un an après, je profite de l'occasion pour faire un point sur la façon dont nos pratiques ont évolué, et les choses sur lesquelles j'aimerais avancer suite à mon expérience du raid.

    En un an, nous avons progressé sur pas mal d'aspects à Toulouse :

    • Nous travaillons plus en équipe, chaque individu étant maintenant apte à intervenir sur davantage de projets différents. C'est extrêmement positif, puisque cela permet mieux de gérer la charge, surtout dans un contexte où nous sommes peu nombreux et intervenons sur beaucoup de projets petits à moyens, avec des dates butoir parfois serrées et des congés à gérer. Une montée en compétence a été réalisée au passage, et j'ai l'impression que globalement l'esprit d'équipe et la communication en ont été renforcés.
    • Après pas mal de réflexion et d'évolutions, notre "kanban" est maintenant un peu plus stable (il ressemble à un kanban mais n'en est pas vraiment un, car pas de limites ni de flux tiré). Nous utilisons les colonnes classiques "backlog", "ready", "doing", "review", et une ligne par projet en cours. Sur chaque post-it contenant une tâche, on ajoute une pastille de couleur représentant la personne en charge de sa réalisation. Un coup d’œil rapide permet donc de visualiser les projets sur lesquels il y a trop de travail en attente, en cours ou à intégrer, ainsi que les sous-charges ou surcharges des membres de l'équipe.
    • Toujours dans la catégorie du management visuel: nous avons maintenant un tableau d'obstacles, ainsi qu'un "tableau des contraintes" (mis à jour une fois par semaine) permettant de résumer par projet les risques, dates butoir, charge restante, absence de membres de l'équipe de développement, etc. Ce tableau facilite l'affectation des membres de l'équipe sur les différents projets et le respect des délais.
    • Nous avons effectué deux delegation board à un an d'intervalle. Cela nous a permis d'identifier des éléments clé dans notre travail au quotidien, de clarifier les rôles les concernant et de soulever des problèmes liés. On a pu noter des améliorations lors de la seconde session, par rapport à la première (principalement au niveau organisationnel).
    • Nous essayons de faire une rétrospective tous les mois. Celles que nous avons faites nous ont permis d'améliorer nos pratiques (nous avons notamment progressé sur nos réunions debout, et sur des notions de qualité via la rédaction commune d'un working agreement)

    En revanche, nous avons un nouveau fauteuil que personne n'utilise (peut-être ressemble-t-il trop à une chaise de bureau, me souffle-t-on dans l'oreillette) ! La question du rythme soutenable mentionnée par Sylvain ne semble pas être la préocupation principale, peut-être parce que malgré la charge fluctuante liée au contexte du travail dans une petite société de service, nous n'atteignons généralement pas un rythme insoutenable.

    Au cours de l'année à venir, je pense que nous pourrions travailler entre autres sur les points suivants :

    • Continuer à avancer sur le travail en équipe sur les projets, qui mérite d'être encore amélioré.
    • Travailler sur les rétrospectives : faire tourner le facilitateur, essayer de précéder la rétrospective d'un exercice d'"échauffement" pour se mettre dans le bain. Je suis revenue du raid avec de nouvelles idées de format, à tester !
    • Un atelier réalisé au cours du raid consistait à classer une grande quantité de pratiques agiles dans différentes catégories: en cours d'acquisition, acquis, non acquis, non souhaité. Réaliser cet exercice avec l'ensemble de l'équipe amènerait sûrement des discussions intéressantes. Cela permettrait en outre de partager une vision commune, et de repérer les points à améliorer en priorité dans nos pratiques.
    • Si l'occasion se présente, j'aimerais que nous essayions la cotation de l'extrême, découverte au cours du raid, efficace pour estimer grossièrement un gros backlog en peu de temps.
    • Utiliser dès que possible une partie des outils de définition de produit vus au cours du raid

  • Logilab était au Forum des Archivistes 2016

    2016/04/19 by Marla Da Silva

    Adrien Di Mascio représentait Logilab les jeudi 31 mars et vendredi 1er avril au congrès de l'Association des Archivistes Français qui s'est tenu à Troyes.

    https://www.logilab.org/file/5496185/raw

    Travaillant de plus en plus avec le monde des archives, notamment au travers du projet SAEM et de la réalisation du futur portail national FranceArchives, ce forum était pour nous l'occasion de nouer de nouveaux contacts et de nous tenir informés des projets en cours.

    Notre premier constat a été que le congrès a eu beaucoup de succès avec plus de 800 inscrits, un peu difficile donc de s'y retrouver une fois arrivés sur place !

    Nous n'avons pas pu assister à la table-ronde « Open data : promesses, prouesses et compromis », qui a eu lieu mercredi 30 mars. À cette occasion, Ruth Martinez a présenté le projet LibreThéâtre: une bibliothèque numérique des œuvres théâtrales du domaine public en téléchargement gratuit, un projet développé par nos soins.

    https://www.logilab.org/file/5557170/raw

    Pendant que les différentes AG se déroulaient, nous avons échangé avec quelques éditeurs de logiciels de gestion et publication des archives, notamment autour des questions des choix d'encodage EAD et en particulier de la possibilité (ou non) de pouvoir reconstruire une URL complète à partir des informations trouvées dans les nœuds dao qui ne contiennent souvent qu'un identifiant interne opaque. Dans ce cas, il est difficile de pointer directement vers l'élément numérisé même s'il est visible en ligne à travers une visionneuse.

    Nous avons enchaîné avec l'atelier sur ARK animé par Sébastien Peyrard et Jean-Philippe Tramoni de la BnF. Cela fait 5 ans que nous travaillons à la réalisation de http://data.bnf.fr/ ; connaissant très bien ce sujet, notre objectif était surtout d'écouter les questions des participants.

    Le reste de l'après-midi a surtout été consacré à moultes discussions sur la visualisation, la recherche et les attentes (imaginées) du grand public qui effectue des recherches dans les fonds d'archives.

    Le congrès a été l'occasion de découvrir certains beaux projets, notamment le futur http://data.alod.ch/ qui permettra d'exploiter les principes du Linked-Data et regroupera des données d'archives de plusieurs partenaires suisses. Nous avons hâte de voir les premières ébauches de l'interface de navigation.

    Petite déception du voyage : ne pas avoir pu assister aux ateliers datasprint


  • Nous étions à pgDay, à Paris !

    2016/04/13 by Marla Da Silva

    Le 31 mars 2016, nous (David Douard et Julien Cristau) avons assisté à pgDay Paris, journée de conférences et d'échanges organisée par la communauté française et européenne de PostgreSQL.

    https://www.logilab.org/file/5463130/raw

    Sauvegardes

    Le matin, Magnus Hagander a donné des conseils sur les outils à utiliser pour faire des sauvegardes de bases postgreSQL. En résumé : ne pas écrire ses propres scripts de backup, ne pas utiliser pg_dump sauf si on tient à passer des heures de downtime à attendre le restore (on se souviendra qu'un backup a un comportement heisenbergien : tant qu'il n'a pas été restauré, son état est indéfini).

    I don't care how long a backup takes, I care about how long a restore takes!

    Magnus a insisté sur le temps que nécessite un restore comme une variable importante à prendre en compte (et qui disqualifie de facto l'utilisation de pg_dump).

    Il est préférable d'utiliser barman ou pg_basebackup et pg_receivexlog pour faire des backups physiques du cluster et conserver le WAL (donc avec une granularité au niveau de la transaction).

    À l'issue de sa présentation, Magnus a lancé un joli "Now, go home and rewrite your backup scripts!".

    Supervision

    Ensuite, Damien Clochard a présenté un rapide tour d’horizon des solutions de supervision pour PostgreSQL. L’occasion de présenter l’état de l’art de l’écosystème Postgres en matière d’outil de visualisation, depuis les classiques/génériques à la nagios jusqu'à des outils plus spécialisés (et précis) permettant de voir les problèmes de performance au niveau d'une application. On en retiendra trois.

    PGObserver est un outil d'analyse et de supervision de cluster Postgresql qui offre une interface web écrite en Python et un agent de récolement des données en Java.

    PGcluu permet d'auditer et d'analyser les performances d'un cluster Postgresql.

    pgBadger est un outil d'analyse des logs PostgreSQL qui est écrit en Perle, fonctionne en ligne de commande et produit des rapports HTML plutôt élégants.

    Et aussi

    Cette journée a été aussi l'occasion de rencontrer et d'échanger avec d'autres utilisateurs de PostgreSQL, ce qui est toujours très enrichissant. Par exemple, au détour d'une conversation avec Dimitri Fontaine, j'ai découvert la "licence morale". C'est sous cette licence qu'il publie son (formidable) outil d'import de données dans Postgresql, pgloader. Avec cette licence (dont il a volé l'idée à Varnish), c'est très simple :

    Happy pgloader users tell me that they want a pgloader Moral License. I send them an invoice from my company. They pay the invoice, I develop pgloader.

    Cerise sur la gâteau, Magnus nous a fait la surprise de sortir toute une série de versions de PostgreSQL on stage.


  • Mon premier Agile Games

    2016/03/15 by Sylvain Thenault

    Vendredi et samedi dernier j'ai participé à la 6ème édition de la non-conférence Agile Games France. J'étais assez privilégié sur ce coup-là puisqu'en plus de faire partie des heureux possesseurs d'une entrée, l'événement se déroulait dans mon village, Nailloux ! Voici un petit compte-rendu de ces deux jours.

    Pour commencer il faut savoir que Agile Games est une "non-conférence" : tout est auto-organisé, depuis le choix du lieu jusqu'à la sélection du programme en live. Comme dit Alex, "c'est un peu comme un forum ouvert, mais en moins organisé" ! Chacun affiche sur un mur les jeux qu'il se propose d'animer, voire ceux auxquels il voudrait jouer dans l'espoir que quelqu'un se propose. Ensuite c'est parti ! Et ça marche, moyennant qu'il ne faut pas rater le coche lorsqu'un jeu qui vous intéresse démarre.

    https://www.logilab.org/4980434?vid=download

    Le journée du vendredi a commencé pour moi par le cube bleu. L'objectif est de montrer notre rapport à l'engagement : comme chacun fonctionne différemment face à un engagement, ou encore la différence entre prendre un engagement individuel par rapport à un engagement collectif. Excellent rapport ludicité / apprentissage de mon point de vue.

    J'ai ensuite pas mal papilloné sans vraiment m'installer nulle part : crayon d'Ariane, Néo le robot agile, Playing lean ou encore le Bikascrum... Il y a de l'activité partout et même ainsi on ne s'ennuie pas. J'ai fini par m'installer en début d'après-midi dans un atelier aidant à comprendre et appliquer les principes de la communication non-violente. L'exercice est difficile mais intéressant (j'avoue être impressionné par la maitrise d'Isabel). Enfin, la journée s'est achevée par une petite dégustation de vin : "In vino veritas", animé par l'équipe nantaise d'Agile Garden. On y a approché la différence entre les résultats obtenus de manière individuelle ou en groupe, sans modération particulière. Comme souvent, la vérité est dans un compromis, ou du moins dans une approche permettant à chacun de s'exprimer.

    Le samedi j'ai attaqué par un icebreaker créatif : commencer par dessiner son voisin, histoire de mettre chacun à l'aise, avant de faire par équipe une mind-map libre, que l'autre équipe devra deviner en partant des feuilles. Et pour encore plus d'énergie, un bon temps dehors pour un chifoumi collectif déjanté, avant de faire un parallèle entre le théatre d'improvisation et les valeurs de l'agilité.

    https://www.logilab.org/file/4980425?vid=download

    L'après-midi, ce fut un energizer collectif "Zoom" autour de l'auto-organisation, planète derdian sur le thème de l'interculturalité, ball point game pour illustrer les interactions équipe / client dans un cadre agile, ou encore un début de jeu expérimental d'Alex où l'on met en place une chorégraphie pour illustrer la conduite du changement.

    Voilà. Et je ne vous parle pas des rencontres, des moments de discussion ou encore du tas d'autres jeux auxquels je n'ai pas participé (improvement kata, beer game, pompafric et autres jeux de cartes et de plateaux)... Bref, un moment plein d'énergie dont on repart ressourcé et inspiré. C'était mon premier Agile Games, et j'espère bien en faire plein d'autres !

    Si vous voulez en savoir plus ou trouver des liens sur les jeux cités, vous pouvez aller voir les billets de Chris ou encore celui de Fabrice.

    https://www.logilab.org/file/4980413?vid=download

    (photo by B.Cabanne)

    Merci à tous les non-organisateurs et participants, et en particulier à Claude pour m'avoir aiguillé jusque là.


  • Présentation de salt + graphite + grafana au Nantes Monitoring Meetup

    2016/03/11 by Arthur Lutz

    Suite à quelques participations au Nantes Monitoring Meetup, notamment un atelier sur Riemann et une présentation plus généraliste sur la supervision (dont j'ai fait un compte rendu), je vais participer au prochain meetup en présentant ce que nous faisons à Logilab en terme de supervision active avec les agents Salt et de visualisation de métriques dans Grafana. Je ferai une présentation principalement basée sur une démo, dont le code est publié sur bitbucket (avec du docker et docker-compose).

    https://www.logilab.org/file/4858408/raw/grafana_demo_dasboard.jpg

    L'atelier porte sur Grafana mais aussi influxdb sur lequel nous avons fait quelques expérimentations, mais ca sera l'occasion d'approfondir nos connaissances sur cet outil concurrent ou complémentaire de Graphite (pour lequel nous commençons à utiliser l'excellent graphite-api). Ca se passe à 19h à la Cantine Numérique à Nantes et l'inscription est gratuite, mais obligatoire.

    À lundi ?


  • Retour sur le meetup 'Big Data from space'

    2016/02/23 by Yann Voté

    Le 11e meet-up du groupe Toulouse Data Science s'est déroulé le mercredi 18 mars à 18h 30 à la Cantine de Toulouse. Le sujet était Big Data from Space : un retour d'expérience du CNES sur les problématiques Big Data en lien avec le programme européen Copernicus.

    La présentation était scindée en deux parties. Dans la masse des images satellites produites par Copernicus :

    • comment pouvoir trouver facilement celles qui nous intéressent ?
    • Et une fois qu'on les a, comment pouvoir en faire quelque chose d'utile sans les télécharger ?
    https://www.logilab.org/file/4519952?vid=download

    La première partie, par Jérôme Gasperi, et dont les diapos sont disponibles sur slideshare, introduisait donc la problématique de l'indexation d'un gros volume d'images satellites. Jérôme commence par rappeler que les métadonnées fournies nativement avec une image satellite sont plus ou moins les mêmes qu'avec un appareil photo : date et heure de la prise, capteur, etc. On y trouve aussi les coordonnées de l'emprise au sol de l'image (bounding box). Ces métadonnées permettent de chercher des images sur une zone donnée dans une période donnée mais sont très insuffisantes pour répondre à des requêtes du genre « je veux les images qui contiennent une ville et une forêt ».

    Pour ce genre de requêtes, la méthode traditionnelle consiste à effectuer une classification supervisée de l'image avec des algorithmes d'apprentissage automatique (meilleures résultats obtenus avec SVM) : j'indique à la machine sur un jeu d'entraînement ce que sont une forêt et une ville, et elle est alors capable de segmenter l'image en zones et de classer chaque zone dans une des catégories indiquées. Le problème est que cette méthode est longue : jusqu'à 15 minutes sur des images a très haute résolution et donc inadaptée pour le volume de données produites par Copernicus (jusqu'à 1 To par jour).

    Une autre option est le deep learning. Jérôme pense que ce n'est pas non plus adapté aux images satellites, mais il a été contredit par plusieurs personnes dans la salle qui ont parlé de travaux montrant que c'était possible. Par exemple : https://www.cs.toronto.edu/~hinton/absps/road_detection.pdf.

    La solution présentée utilise le croisement avec des données exogènes : au lieu de se contenter des pixels de l'image, pourquoi ne pas utiliser des informations accessibles par ailleurs ? Par exemple avec l'emprise et des données d'occupation du sol on peut dire si l'image intersecte une forêt et une ville. Avec des données administratives, on peut dire quels pays sont concernés par l'image. Avec la date et des données météorologiques, on peut dire le temps qu'il faisait au moment de la prise de vue. Jérôme a donc développé iTag (est-il Apple addict ?) qui permet de croiser ce genre d'informations et d'ajouter des tags aux métadonnées d'une image. Cela prend quelques milli-secondes: contre plusieurs minutes pour une classification, le gain est énorme.

    Un dernier point : il a aussi montré sur son démonstrateur (non accessible pour l'heure) comment il présentait les résultats d'une recherche sous la forme d'une carte de chaleur. En effet, contrairement à une recherche Google où les résultats sont triés par pertinence, ici le moteur ne sait pas faire ce tri. Les résultats sont donc présentés sur une carte du monde et des points de couleurs viennent montrer la densité des résultats : bleu s'il y a pas ou peu d'images qui correspondent aux critères sur cette zone ; rouge s'il y en a beaucoup.


    La seconde partie, par Pierre-Marie Brunet, peut se résumer en une phrase : il vaut mieux rapprocher le calcul de la donnée que l'inverse.

    Partant du constat que les données aujourd'hui sont de plus en plus gratuites, et que la véritable valeur se situe dans les algorithmes de traitement sur ces données, l'enjeu est d'éviter que tout un chacun vienne moissonner les images Copernicus, les télécharge chez lui pour en faire ce que bon lui semble : vu les volumes à télécharger, cela mettrait le réseau à genou.

    J'ajoute ce commentaire personnel : le documentaire « Internet, la pollution cachée » diffusé sur France 5 en 2014, bien que discutable dans ses calculs et dans ses partis pris, permet de se rendre compte de ce que coûte l'envoi d'un simple mail.

    Il s'agit donc de permettre aux usagers de demander à la plate-forme d'effectuer elle-même les traitements dont ils ont besoin, grâce par exemple au protocole WPS de l'OGC, et de télécharger plutôt le résultat de ces traitements.

    Vu le nombre d'utilisateurs possibles, cela demande de mettre en place une infrastructure de calcul conséquente. Le rapprochement du HPC et du Big Data : le Big Processing.

    Avec cette expérience accumulée, l'architecture cible pour Copernicus sera donc fondée pour la partie logicielle sur Hadoop, Spark, Elasticsearch et Kibana. Mais le plus intéressant est la vision haut-niveau : un ordonnanceur, dont j'ai oublié le nom, aura une information en temps réel sur l'état des nœuds de calcul, sur la répartition des données et sur la vitesse de transfert entre les données et les nœuds. Mieux, chaque nœud sera capable de faire tourner des conteneurs Docker, et il y aura un registre d'images Docker, local et distribué lui aussi. Par conséquent, pour un calcul demandé par un usager :

    • ce calcul correspond par exemple à une image Docker compute et concerne des données facilement accessibles par le nœud A ;
    • l'ordonnanceur va donc demander au nœud A d'exécuter l'image compute sur les données concernées ;

    On retrouve bien le principe : les calculs sont rapprochés des données (même si on ne s'interdit pas de déplacer les données).

    L'utilisation de Docker a d'autres avantages :

    • les usagers pourront proposer leur propres images pour réaliser des calculs dont ils ont besoin et qui ne seraient pas encore proposés ;
    • les centres de calcul étant répartis dans les différents pays européens pour Copernicus, chaque centre a ses spécificités (distribution GNU/Linux différente d'un centre à l'autre par exemple). Comme il n'est pas question d'imposer un choix (à part Docker), Docker permet de faire tourner des calculs dans tous les centres quelles qu'en soient les spécificités.

    Tout ceci ressemble beaucoup à ce que nous avons fait pour Simulagora.


  • Châtaignes, Saucisson et Méthodes agiles... on était au Raid Agile #4 !

    2016/02/15 by Marla Da Silva

    Adrien, David, Katia et moi avons participé au 4ème raid agile organisé par Pablo Pernot et Claude Aubry dans les Cévennes.

    https://www.logilab.org/file/4386083?vid=download

    Je partage l'avis de Sylvain Thénault, lorsqu'il a dit ici il y a quelques mois "j'ai eu la chance de participer au raid agile organisé par Pablo et Claudio", car à mon avis, c'est vraiment une chance de pouvoir se retrouver dans un gîte des Cévennes pour une formation agile originale pendant trois jours et trois nuits. Pendant cette formation, on arrête tout et on partage ses expériences, on joue, on randonne ensemble, et surtout on apprend les nouvelles pratiques du management, de l’agilité organisationnelle et de la gestion de produit. On parle, bien sûr, de participer à des ateliers d'impact mapping, de story mapping, de faire des échanges sur Scrum, Kanban et d'approfondir ses connaissances sur la culture agile.

    Malgré un côté un peu "monomaniaque" (on est isolé au milieu de nulle part, on fait des randonnées, on arrive en haut de la montagne et on ne parle que des méthodes agiles), à aucun moment on ne parle de vie personnelle, ce qui permet de vite se couper du monde extérieur et s'impliquer dans les jeux. Les profils distincts des participants (grands groupes, PME et indépendants) a permis d'échanger et de se rendre compte que les problèmes ne sont pas si différents et qu'on peut trouver un moyen d'adapter l'agilité pour les résoudre.

    Je n'ai pas pu m'empêcher de réfléchir à ce qu'on pourrait mettre en œuvre pour améliorer les pratiques agiles déjà instaurées au sein de Logilab. Ce qui est intéressant, c'est que je me suis toujours dit que les méthodes agiles ne s'appliquaient qu'aux développeurs, et désormais j'ai vu qu'on peut appliquer cette nouvelle façon de travailler dans tous les domaines d'activité dont celui de la communication.

    Je pense surtout au chef de projet qui doit mener son projet à terme tout en respectant les délais et surtout le budget dédié. Et pour atteindre son objectif, le chef de projet doit penser au contenu, au calendrier, au budget mais aussi à la satisfaction du client (et j'ajouterais même "à sa fidélisation"). À travers les méthodes classiques, on se voit confier le projet, on le démarre et on avance... selon une ligne droite : on valide l'étape précédente avant de passer à la suivante. Sauf qu'il arrive (et très souvent) qu'on ne valide pas l'étape précédente et que, par manque de temps ou de budget, on fonce vers l'étape suivante. Il en résulte un très grand stress et s'il faut revenir en arrière pour corriger un problème, c'est toujours plus coûteux.

    https://www.logilab.org/file/4386092?vid=download

    Dans les méthodes agiles, on nous propose de découper le travail en plusieurs itérations, qu'on gère en tant que "mini-projets" définis avec le client. Ensuite on identifiera — toujours avec le client — les différentes fonctionnalités et leur priorité. Résultat : le client pourra clarifier ses attentes et ses exigences pendant que le projet avance et il se sentira rassuré d'avoir une meilleure visibilité sur le projet (objectifs à court terme livrés régulièrement). L'amélioration se fait en continu, la qualité reste tout le temps contrôlée et les risques sont identifiés au plus tôt. Tout au long du projet, l'équipe reste motivée car ses objectifs sont toujours proches et sont régulièrement atteints (à chaque fin d'itération). Et s'il arrive qu'il n'y ait plus de budget, le projet peut s'arrêter sereinement et le client n'est pas surpris car il a suivi l'évolution du projet.

    Dans les méthodes agiles on se focalise sur l'objectif, on découpe le temps, on fixe des échéances, on propose des livraisons fréquentes, on suggère des aménagements en permanence, on communique avec ses collègues, son équipe et le client (on parle d'un échange étroit entre toutes les parties prenantes, une réflexion constante,) et surtout... on accepte le changement.

    https://www.logilab.org/file/4386097?vid=download

    Par exemple, nous avons appris la méthode Scrum grâce à un exercice consistant à faire ensemble un puzzle de 500 pièces. 3 équipes de 3 personnes ont été formées. À cette occasion nous avons dû :

    • déterminer les exigences du client (son objectif : le puzzle monté),
    • identifier les priorités (quelles étaient les parties que le client souhaitait voir réalisées en premier et pourquoi),

    Des mêlées ont été organisées à la fin des sprints de réalisation afin de contrôler l'avancement du projet. Ceci nous a permis de faire un rapport qualitatif et quantitatif du projet. Le client nous a fait part de son mécontentement, et nous avons pu expliquer que le produit ne pourrait pas être livré dans le délai souhaité. Le client a donc pu comprendre nos contraintes et nous avons pu trouver ensemble une solution satisfaisante.

    Ce jeu m'a permis de comprendre scrum et m'a montré son efficacité. Je comprends mieux pourquoi chez Logilab nous appliquons les méthodes agiles à nos développements et tous nos projets.

    https://www.logilab.org/file/4386104?vid=download

    L'ensemble des outils évoqués tout au long du raid s'appuie sur du matériel issu du mouvement agile. Le contenu est dense, on enchaîne les jeux à grande vitesse, et malgré (ou grâce à) des visions souvent opposées, Pablo et Claude ont su nous immerger dans l’agilité.

    Je ne saurais trop vous recommander de sauter sur l'occasion et de participer à une prochaine édition du raid !


  • Nous allons à FOSDEM 2016 et cfgmgmtcamp

    2016/01/18 by Arthur Lutz

    FOSDEM est le rendez-vous incontournable du logiciel libre en Europe. Logilab y participe depuis plusieurs années (en 2013 avec changeset evolution dans mercurial , puis en 2014 sur PostgreSQL, 2015 en tant que participants).

    https://www.logilab.org/file/3819974/raw/wide.png

    Cette année, nous allons donc participer à FOSDEM dans le track Configuration Management devroom, je presenterai Salt en mettant l'accent sur la supervision orchestrée par ce framework en collectant les données dans graphite et les exploitant dans grafana.

    Nous profitons d'être en Belgique pour enchaîner avec cfgmgmtcamp "Config Management Camp" qui se déroulera les jours suivants à Gent (1er et 2 février). J'y présenterai à peu près la même chose dans le cadre du Track "Salt". N'hésitez pas à jeter un coup d'œil à l'ensemble des présentations qui promettent d'être passionnantes.

    https://www.logilab.org/file/3819969/raw/cfgmngmentcamp.png

    Si vous allez à l'un de ces événements, faites-nous signe qu'on en profite pour se voir. Nous nous efforcerons de partager une partie de ce que nous aurons appris lors de nos pérégrinations dans un article de blog, donc "watch this space" et nos comptes twitter (@arthurlutz, @douardda, @logilab).


  • Compte rendu meetup Agile Nantes - #lego4devops

    2016/01/08 by Arthur Lutz

    Mercredi soir, j'ai participé avec beaucoup de plaisir au meetup mensuel d'agile nantes "Vos voeux 2016 et Lego4DevOps.

    Au delà d'une session "papillons repositionables" pour que les participants expriment leurs souhaits pour les sessions mensuelles de cette année, nous avons joué à #lego4devops, jeu de lego inspiré de lego4scrum.

    Étant intéressé par les problématiques que l'approche devops cherche à résoudre j'étais assez content de participer à cet atelier. En résumé, il s'agit d'un jeu où une équipe ops et une équipe dev doivent collaborer pour livrer des fonctionnalités à un client sur une plateforme qui doit avoir un maximum de disponibilité (et donc de stabilité). Chaque session de développement / mise en production (3 minutes) est entrecoupée d'une petite session de rétrospective (4 minutes) pour discuter des améliorations à apporter. On compte à chaque fin d'itération le nombre de fonctionnalités livrées, le nombre de fonctionnalités en production et la disponibilité de la plateforme.

    Photo de Axel Villechalane

    Photo de Axel Villechalane

    On voit rapidement des problèmes (et des solutions) similaires à ce qu'on peut retrouver en entreprise, les animateurs ajoutant des exemples ou anecdotes mettant en avant ces travers et le rapportant aux bonnes pratiques du mouvement devops.

    Le jeu est disponible en licence creative commons, les PDFs sont disponibles ici : jeu #lego4devops. À faire tourner, essayer et améliorer. Merci à l'association Agile Nantes ainsi qu'à Sébastien Fauvel et Cécile Especel.

    http://www.agilenantes.org/wp-content/themes/agilenantes_theme/img/logo_agilenantes_200.png

  • Remettre en jeu le passé à la Comédie-Française

    2015/12/18 by Adrien Di Mascio

    Mercredi 16 décembre dernier se tenait à l'Institut National d'Histoire de l'Art la troisième journée du colloque Remettre en jeu le passé - Métamorphoses du corpus des Registres de la Comédie-Française auquel nous avons eu le plaisir de participer.

    Cette dernière journée a débuté par une présentation d'Agathe Sanjuan et de Sara Harvey sur l'historique du projet des registres de la Comédie-Française et son positionnement dans le cadre des humanités numériques.

    http://cfregisters.org/img/cfrp-logo-top-nav.png

    Collection ou fonds d'archive ?

    Tout d'abord, Agathe et Sara ont présenté les problématiques des Humanités Numériques comme étant proches de celles des métiers de la documentation aujourd'hui, idée que nous pouvons étayer par notre propre expérience, qui consiste à mettre au service de communautés comme celle de chercheurs des données qui sont issues des catalogues de la Bibliothèque nationale de France.

    Si les problématiques sont donc les mêmes, à savoir notamment la volonté d'être un support ouvert pour une vaste communauté de chercheurs, Agathe Sanjuan et Sara Harvey ont cependant souligné le fait que la collection des Registres de la Comédie-Française n'a de collection que le nom. Il s'agit en réalité d'un fonds d'archive, produit dans le cadre de l'activité de l'institution qui les a vus naître, et non de données spécifiquement produites dans un but de description documentaire avec pour cible une communauté de lecteurs ou chercheurs.

    Le document d'archive au crible du traitement massif de données

    Les nouvelles perspectives introduites par le traitement massif de données changent notre manière d'approcher l'objet archivistique. Il ne s'agit plus uniquement de traiter qualitativement un corpus de documents qui, par leur mise en résonance, permettent de produire de nouvelles connaissances, mais également d'entrer plus finement encore à l'intérieur du document au niveau de l'unité que représente l'information elle-même. Il devient alors possible d'agréger cette unité informationnelle à une masse considérable d'informations prélevées dans le même contexte documentaire.

    Une médiation toujours nécessaire

    L'échelle de l'observation ou du traitement change à la fois du fait de la fragmentation du matériel brut et de la masse considérable de ce matériel une fois agrégé. Pour autant, la nature même de ce matériel, à savoir sa nature documentaire et archivistique, ne semble guère évoluer du point de vue des problématiques qu'il pose. Si l'archive nécessitait l'apport d'un professionnel érudit et fin connaisseur de son contexte de production pour être comprise, la donnée issue de ces corpus d'archives ne se laisse pas aborder de manière plus évidente et immédiate. Il est a minima nécessaire d'indiquer sa provenance et le sens qui a présidé à sa production.

    L'interopérabilité comme source d'enrichissement

    http://www.w3.org/wiki/images/e/e1/SweoIG$$TaskForces$$Logos$$SemWebTechLogoIdeas$rdf.png

    Le traitement documentaire au niveau de la donnée et non plus de l'unité documentaire présente l'immense avantage de pouvoir ouvrir le corpus sur lequel travaille le sujet et de le mettre en perspective avec des corpus similaires, du fait de l'interopérabilité de ses données.

    La mise en correspondance massive de ces données semble par ailleurs montrer que les connaissances produites dans ce contexte s'attacheraient moins à l'individualité de l'information qu'à l'observation des tendances plus générales.

    Le hackathon !

    Au cours de cette journée, la pratique a ensuite succédé à la théorie avec la présentation par Jamie Folsom et Christopher York (MIT) de leur travail visible sur http://cfregisters.org/en/the-data, et les différents moyens actuels d'accéder et de manipuler les données, essentiellement :

    Les deux premiers outils de cette liste sont d'une grande efficacité mais le manque d'ergonomie et de médiation en font des outils complexes pour le public non expérimenté, même lorsqu'il connaît le fonds sous-jacent. L'accès CSV est simple et permet de charger les données dans des tableurs classiques mais on ne peut alors plus naviguer et fureter dans les données comme on le ferait dans une interface web. Enfin, l'accès au JSON est quant à  lui plus réservé aux développeurs.

    D'une manière générale, le projet global de visualisation des données des Registres de la Comédie-Française nous a paru être marqué par une double volonté :

    • visualiser pour produire des connaissances, notamment à l'appui des recherches variées et spécifiques des chercheurs qui s'intéressent au corpus, ce que caractérise l'outil déjà existant du tableau croisé dynamique ;
    • faire découvrir le corpus en proposant une navigation au sein même des données, comme en témoigne le navigateur à facettes.

    Ainsi, le hackathon qui s'est déroulé de 11h30 à 17h30 avait-il en quelque sorte ce double objectif de proposer un outil polyvalent et simple d'utilisation au chercheur mais aussi de lui faire découvrir de manière ludique le corpus. L'équipe du hackathon a travaillé tout particulièrement sur :

    • l'interopérabilité, à savoir la standardisation du modèle de données, des formats d'échange, l'ajout d'alignements sur les autorités de la BnF, les alignements vers d'autres jeux de données comme celui de la Naissance de la Critique Dramatique , http://data.libretheatre.fr, etc.
    • la visualisation, avec notamment l'intégration des données des Registres dans l'outil et la base de données Dezede, une analyse réalisée par Frédéric Glorieux sur la popularité et les recettes rapportées par les représentations d'auteurs dramatiques comme Voltaire, Molière, Corneille ou Racine.

    Notre travail personnel est visible en ligne avec les précautions d'usage habituelles qui sont rappelées sur la page d'accueil.

    La question se pose désormais de savoir comment envisager la suite de cet atelier caractérisé d'une part par des besoins simples correspondant au besoin de visualiser l'information par saison, par auteur, par pièce… et d'autre part, par des besoins plus long-termistes, à savoir un effort ergonomique et de médiation autour de l'existant déjà très avancé afin de transformer des utilisateurs novices en utilisateurs experts : la visualisation, pour être lisible, doit en effet s'accompagner d'un design et d'une introduction textuelle qui permette de faire l'interface entre complexité des données et novicité des utilisateurs découvrant pour la première fois le projet.

    Cette journée, admirablement organisée par Agathe Sanjuan et Sara Harvey, a été l'occasion de rencontres et discussions passionnantes avec les autres participants au hackathon et Damien Chardonnet.

    Raphaëlle Lapôtre (BnF) - Adrien Di Mascio


  • Agile Tour Toulouse 2015

    2015/11/30 by Denis Laxalde

    La semaine dernière, plusieurs Logilabiens ont assisté à l'Agile Tour à Toulouse. Le thème de cette huitième édition était le bonheur au travail.

    Le format de la première journée, qui a vu passer environ 300 personnes, alternait entre conférences "classiques" et ateliers participatifs tandis que la deuxième journée, plus intimiste, s'est (auto-)organisée en un forum ouvert où les participants choisissaient et animaient les ateliers qui leur plaisaient. Voir le programme ainsi que les feedbacks.

    affiche attls 2015

    J1: ateliers et conférences

    En ouverture, la comédie humaine du travail de Danièle Linhart nous a plongé dans l'histoire de l'organisation du travail dans les entreprises et son évolution depuis les travaux de Taylor. Peu de rapport direct avec l'agilité, si ce n'est une question (qui est par ailleurs revenue lors des questions / réponses) : dans quelle mesure la mise en pratique de l'agilité dans les entreprises est-elle vraiment différente des différents avatars du taylorisme dont l'objectif reste de déposséder les travailleurs de leur savoir, c'est-à-dire de leur pouvoir ? La question reste ouverte...

    Dans un registre plus technique, Baptiste Mathus nous a présenté sa forge logicielle aux petits oignons : un bon retour d'expérience qui nous rappelle que l'agilité du point de vue technique passe par la maîtrise des outils au quotidien. Quelques éléments intéressants aussi quant aux problématiques de conduite du changement vis-à-vis des principes du lean sofware development (de l'intérêt des radiateurs d'information par exemple) ou encore de l'utilité du shadow IT.

    La conférence d'Olivier Azeau nous a rappelé (trop rapidement) les principes du #NoEstimates. Thème repris par l'atelier sur l'art d'avoir tort animé Christophe Heral dans l'après-midi.

    La plénière d'ouverture de l'après-midi était assurée par Luc Pouliquen d'Airbus : longue dissertation sur l'impact supposé de l'application des principes de l'Agile Manifesto sur un projet fictif dans une entreprise comme Airbus. Les présentations qui ont suivies étaient sympathiques, de part le témoignage qu'elles apportaient ou par la performance de l'orateur, mais il faut bien avouer qu'on n'a pas appris grand chose.

    Enfin l'atelier "mettons en mouvement la solution" de Frédéric Duffau était particulièrement intéressant. Celui-ci propose un format de rétrospective basée sur la définition d'un idéal plutôt que sur un mode "cahier de doléances", l'idée étant in fine d'investir chacun dans les actions à prendre.

    J2: open-space

    image

    Le forum ouvert en deuxième journée était bien agréable, peut être plus instructif que la première journée finalement. Quelques ateliers auxquels nous avons participé :

    • la business value : inutilisée en pratique, mais qui peut servir à rappeler l'importance de la valeur du risque (ou d'apprentissage) lors de choix stratégiques ;
    • l'agilité dans les réponses à appels d'offres (surtout lorsqu'ils ne sont pas étiquetés agile) : de l'importance de choisir une méthode éprouvée telle que SCRUM, de former les parties-prenantes à l'agilité et de véhiculer un climat de transparence dans les processus.
    • le recrutement agile : discussions fructueuses autour des idées de questionnaire (graphique) centres d'intérêt / compétences, de suivi de recrutement via des rapports d'étonnement.
    • autour du développeur Heisenberg, celui que l'on ne peut pas observer sans altérer son comportement, nous avons discuté des relations hiérarchiques ou encore des métriques de qualité qui, lorsqu'elles sont imposées par les équipes qualité sont souvent absconses voire contre-productives ; la voie est sans doute dans le bon usage des working agreements.
    • la rétrospective dans la durée, ou quoi faire varier pour ne pas s'essoufler en dehors des formats (en étoile, speed-boat, las vegas, mise en avant de la solution évoqué plus haut, à base de dixit...). Quelques pistes : le lieu, l'animateur, le sujet...
    • pitch elevator agile : l'agilité c'est quoi ? pour qui ? pour quoi ? comment ça se compare ? quels sont ses avantages et sa valeur ? Nous avons chacun tenté l'exercice du pitch avec plus ou moins de succès, mais force est de constater que cela s'améliorait au fur et à mesure. On retient de l'exercice qu'il faut faire attention à se décentrer pour s'axer sur son interlocuteur plus que sur sa propre vision.
    • comment interpréter les résultats de niko niko : ben on sait pas trop ! Intéressant pour avoir une tendance globale dans la durée, et éventuellement détecter un problème. Cela fournit notamment des données à reprendre en rétrospective. Quoiqu'il en soit, attention à bien expliquer le but avant de mettre ça en place.
    • l'agilité sur des équipes distribuées, ou comment les projets Open-Source d'envergure restent la source d'inspiration de référence, avec une ou deux semaines de "team building" par an pour consolider les liens et créer une vision d'ensemble.

    Conclusion

    À la vue de tout ça, on se rend compte que nos pratiques, tant en terme d'agilité que d'entreprise libérée, sont plutôt assez développées. Et ça c'est toujours agréable. Comme disait l'autre, « Quand je m’observe, je m’inquiète. Quand je me compare, je me rassure » !

    Évidemment cela reste loin de la perfection, et voici quelques points qu'on aimerait (peut-être) faire à la sortie de cet ATTLS:

    Bref, nous avons passé un moment sans révolution mais enrichissant et qui donne des idées pour les prochains incréments. Agile quoi !

    Donc merci à toute l'équipe d'Agile Toulouse pour l'organisation !


  • Système d'Archivage Électronique Mutualisé

    2015/11/20 by Marla Da Silva

    À l'occasion de l'Open Source Summit Paris 2015 Sylvain Thénault a co-présenté le projet SAEM : Système d'Archivage Électronique Mutualisé en compagnie de Pascal Romain et Pierre-Etienne Cassagnau du Conseil Départemental de la Gironde dans le cadre des retours d'expérience et solutions des entreprises.

    De nos jours, les institutions publiques locales doivent conjuguer efficacité et économie. Cherchant à résoudre cette équation complexe, les services d'Archives du Conseil Départemental de Gironde, de la Métropole de Bordeaux et de la Ville de Bordeaux ont choisi de s'allier pour développer et déployer un Système d'Archivage Électronique Mutualisé (SAEM) construit à partir de logiciels libres.

    https://www.logilab.org/file/2716717/raw/IMG_4603.JPG

    Cette présentation allie le point de vue du client (Conseil Départemental de Gironde) et notre regard technique (Logilab), en particulier sur l'utilisation du logiciel libre CubicWeb et des technologies du Web Sémantique. Vous pouvez la visualiser en HTML et aussi sur slideshare.

    Une prise vidéo a été réalisée et nous partagerons bientôt la vidéo avec vous.


  • Présentation de Salt à Open Source Summit Paris 2015

    2015/11/20 by Arthur Lutz

    Mercredi dernier, David Douard a fait une présentation dans le cadre du track "Devops" au Open Source Summit Paris 2015.

    David a présenté pourquoi configurer et orchestrer son infrastructure avec un outil de gestion de configuration centralisée tel que Salt comporte de nombreux avantages. La conservation et l'historisation des fichiers de configuration dans un entrepôt de source géré par un DVCS (mercurial ou git) en fait partie. Salt permet ensuite de faire évoluer son infrastructure en la testant dans des environnements isolés. Une fois la description complète, reproduire une partie de son infrastructure de production sur un environnement virtualisé tel qu'un cloud privé (OpenStack) devient possible et automatisable avec salt-cloud. L'étape suivante est de pouvoir reproduire des portions de son infrastructure dans des conteneurs légers tels que docker ou lxc directement sur son portable. Pour cela, le pilotage de docker par salt et les fonctionnalités d'orchestration de salt permettent une agilité sans précédent.

    https://pbs.twimg.com/media/CUGwPpJWwAA3Y5l.jpg:large

    Les diapositives sont publiés en HTML (recommandé car la vidéo de démo y est intégrée) mais aussi sur la plateforme slideshare (sans la vidéo).

    La présentation a été filmée et une vidéo sera bientôt publiée par les équipes de la conférence.

    Nous souhaitons remercier les organisateurs pour cette ambitieuse conférence qui touche à beaucoup d'aspects du logiciel libre avec lequel nous travaillons tous les jours à Logilab.


  • Compte rendu Nantes Monitoring Meetup #3

    2015/11/10 by Arthur Lutz

    Hier soir je suis allé faire un tour au meetup "Nantes Monitoring Meetup #3" à la Cantine. La présentation principale était sur le glossaire et vocabulaire du monitoring et aussi sur livestatus qui permet de requêter un système de monitoring (nagios, shinken, etc.).

    Voici quelques liens glanés pour l'occasion de technologies dont nous avons parlé :

    À Logilab, nous avons adopté plusieurs de ces outils pour la supervision de nos services :

    https://www.logilab.org/file/2568077/raw/monitoring_salt_shinken_uptime_graphite_grafana.png

    Dans nos cartons nous avons des choses comme Tessera et Cabot - monitor and alert

    Le prochain meetup aura lieu début janvier et sera sous la forme d'un atelier autour de Riemann, qui semble très prometteur. Inscrivez-vous au meetup pour ne pas rater la prochaine date !

    https://www.pagerduty.com/assets/riemann-logo.png

  • Introduction au tutoriel d'introduction au Web sémantique - SemWeb.Pro 2015

    2015/11/03 by Nicolas Chauvat

    Voici un court texte d'introduction à lire avant de participer au tutoriel qui ouvrira la journée de conférence SemWeb.Pro 2015.

    1940 - Vannevar Bush

    Vannevar Bush est l'un des pionniers d'Internet, à travers notamment son article As We May Think, paru en 1945 dans le magazine Atlantic Monthly, dans lequel il prédit l'invention de l'hypertexte, selon les principes énoncés par Paul Otlet dans son Traité de documentation. Dans cet article, il décrit un système, appelé Memex, sorte d'extension de la mémoire de l'homme. Ce texte jette les bases de l'ordinateur et des réseaux informatiques. Il envisage de pouvoir y stocker des livres, des notes personnelles, des idées et de pouvoir les associer entre elles pour les retrouver facilement. Il y évoque déjà les notions de liens et de parcours, prenant pour modèle le fonctionnement par association du cerveau humain.

    1960 - Ted Nelson

    Ted Nelson ayant imaginé une machine qui permettrait de stocker des données et de les mettre à disposition de tous, partout, il met en place en 1960 le projet Xanadu et tente, avec plus ou moins de succès, de mettre en application ce qu'il nomme « le projet original de l'hypertexte. »

    Le principe de l'hypertexte a été repris par de nombreux pionniers de l'informatique, comme Douglas Engelbart pour mettre au point une interface homme-machine dans les années 1960, Bill Atkinson, chez Apple, pour développer HyperCard, ou encore Tim Berners-Lee en 1989, pour définir les bases du World Wide Web.

    1970 - Internet

    L'internet est le réseau informatique mondial accessible au public. C'est un réseau de réseaux, sans centre névralgique, composé de millions de réseaux aussi bien publics que privés, universitaires, commerciaux et gouvernementaux, eux-mêmes regroupés, en 2014, en 47 000 réseaux autonomes. L'information est transmise par l'internet grâce à un ensemble standardisé de protocoles de transfert de données, qui permet l'élaboration d'applications et de services variés comme le courrier électronique, la messagerie instantanée, le pair-à-pair et le World Wide Web.

    L'internet ayant été popularisé par l'apparition du World Wide Web (WWW), les deux sont parfois confondus par le public non averti. Le World Wide Web n'est pourtant que l'une des applications de l'internet.

    1990 - Tim Berners-Lee

    Tim Berners-Lee travaille en 1989 au Conseil européen pour la recherche nucléaire (CERN), où il est connecté au réseau du centre de recherche et à l'internet. Il propose alors à sa hiérarchie un projet de système de partage des documents informatiques, qu'il a l'idée de réaliser en associant le principe de l’hypertexte à l'utilisation d'Internet. Il déclarera plus tard à ce sujet : « Je n'ai fait que prendre le principe d’hypertexte et le relier au principe du TCP et du DNS et alors – boum ! – ce fut le World Wide Web ! ». Quelques années plus tard, en 1994, lors de la première édition de la conférence WWW, il présente ses idées concernant la manière de faire apparaître les sujets et informations dont traitent les documents publiés sur le web, ce qu'il nomme la sémantique du web.

    2010 - Le web des données liées

    C'est à partir de 2010 qu'explose le nombre de jeux de données publiés sur le web. Lisez la page au sujet de Victor Hugo à la BnF, puis tentez d'interpréter les données équivalentes et de comparer à celles de DBPedia.

    Sources: Wikimedia Foundation, W3C, Lod-Cloud, Xanadu Project


  • Compte rendu de l'équipe Logilab à PyConFR 2015

    2015/10/27 by Arthur Lutz

    Nous étions à PyConFR 2015 avec quelques personnes de l'agence toulousaine de Logilab.

    pyconfr

    Nous avons présenté 3 sujets (annoncés ici), les conférences ont été enregistrées, elles devraient être disponibles bientôt (update les vidéos ont été publiés) :

    https://pbs.twimg.com/media/CRgfK2-UkAEht8z.jpg

    Nous avons vu de nombreuses conférences et discuté python pendant les pauses, voici quelques concepts ou pointeurs qui ont retenu notre attention.

    Côté outils et système

    Le travail qu'effectue Fedora sur son bus de message au niveau de l'infrastructure (fedmsg) est fort intéressant, nous faisons des choses similaires avec le bus d’événements de Salt sur notre infrastructure.

    Toujours chez Fedora, nous allons jeter un œil sur faitout qui permet de récupérer une base de données Postgresql temporaire à utiliser dans les tests unitaires ou l'intégration continue.

    Nous utilisons déjà tox, pour un certain nombre de projets, mais cette présentation nous a motivés pour approfondir quelques pistes : comme detox pour tester les environnements en parallèle. tox permet de lancer les tests unittaires (mais aussi construire la documentation) dans des environnements virtualenv, permettant ainsi de tester une grille de configurations (différentes versions de python, ou de dépendances).

    Guix est un gestionnaire de paquets et une distribution, c'est un projet prometteur, même si nous restons très attachés à Debian. Guix s'inspire du travail effectué par NixOS (dont une présentation avait été faite lors d'un meetup salt). Un peu avant-gardiste, mais probablement utile à terme.

    Bandit, est un outil d'analyse statique qui se focalise sur la sécurité. Il est capable d'analyser du code Python pour détecter les failles de sécurité les plus courantes: SQL injection, XSS, attaque par symlink. Bandit ne fait pas tout (il ne détecte pas le code qui n'existe pas mais qui devrait y être), mais c'est un outil précieux pour automatiser les tests de sécurité et gagner du temps. Bien sûr, la meilleure école pour se former reste de lire les patchs qui corrigent les failles de sécurité et de se faire auditer par des experts. L'analyse de code est un sujet qui nous intéresse, car pylint est né à Logilab et nous travaillons encore sur ces sujets avec astroid (ancien logilab-astng) et safe-python.

    Scapy permet de recevoir, d'envoyer et de manipuler des paquets réseau. Il supporte de nombreux protocoles, et peut être utilisé notamment à des fins d'audit.

    Côté bases de données

    Deux conférences consécutives concernant SQLAlchemy et GeoAlchemy, bien que restant à un niveau de généralités, ont été très instructives. On peut en retenir que, malgré la refonte de l'API avec la version 1.0, les fonctionnalités les plus utiles de SQLAlchemy restent cachées (declarative, back_populate), et les bonnes pratiques sont très mal connues, car mal documentées. La présentation en donnait quelques unes comme "ne jamais faire de requête dans une boucle", ou encore "dans un join, il vaut mieux expliciter toutes les tables". Côté GeoAlchemy, la présentation voulait montrer qu'il est très simple de manipuler des données géométriques avec cet outil développé par la société franco-suisse camp2camp.

    https://pbs.twimg.com/media/CRnaEoFWsAQUL2e.jpg

    Côté python pur

    Comment optimiser le code Python de Mercurial pour qu'il assure des performances suffisantes, quels sont les pièges à éviter ? C'était l'objet de la conférence de Pierre-Yves David, qui a débuté le développement de evolve en 2011 quand il travaillait à Logilab et que nous cherchions à améliorer nos processus de revue de code. Côté astuces, on a retenu entre autres l'utilisation des slots, un mécanisme d'import paresseux (présent en standard dans Python 3), la désactivation ponctuelle du ramasse-miettes ou encore le pré-chargement d'attributs ou de fonctions hors des boucles.

    Nous avons pu assister à une présentation très intéressante sur la tabulation avec Python. La tabulation c'est la mémoïsation poussée à l’extrême: enregistrer tous les résultats d'une fonction pour toutes les valeurs possibles des paramètres. Dingue, non ? La présentation montrait que, moyennant la prise en compte de contraintes techniques (limiter le domaine des paramètres, optimiser le tableau des résultats en le découpant), cela était tout à fait possible, et apportait un gain de temps réel. Mais en fait l’intérêt ne réside pas vraiment dans le fait de mettre en cache des résultats pour gagner en temps de calcul ; non, il s'agit plutôt de masquer le code d'une fonction. Au lieu de fournir à l'utilisateur une version compilée qui risque de faire l'objet de rétro-ingénierie, on lui fournit le tableau des valeurs possibles en entrée et le tableau des résultats correspondants en sortie. La probabilité de retrouver l'algorithme est alors moindre, surtout pour des fonctions de type hachage que certaines sociétés tiennent à garder secrètes.

    Côté communauté

    La conférence sur les communautés locales nous a intéressé étant donné notre implication dans les meetups salt, les meetup python à Nantes et nos organisations de communautés autour de CubicWeb, de certains codes de calculs libres et du web sémantique. La lecture de The art of community online nous a été recommandé par Alexandre Fayolle, grand ancien de Logilab, qui en a bénéficié pour sa participation à l'Odoo Community Association.

    Côté CubicWeb

    Hospital avec ses healthchecks en production pourrait être un bon candidat pour nos applications CubicWeb qui sont déjà branchées sur du statsd pour les métriques métier et sentry pour la collecte d'anomalies. Le projet qui n'en est encore qu'à ses débuts mais contient certaines idées intéressantes. L'objectif est de pouvoir tester les déploiements d'une application. Les outils qui existent ne permettent d'avoir qu'une partie de l'objectif:

    • les tests automatiques, même fonctionnels, testent l'application hors de son environnement final. Ou alors il peut être long de les lancer une fois l'application déployée ;
    • la supervision permet de détecter les problèmes mais l'application est vue comme une boîte noire: savoir qu'il y a une erreur 500 ne permet pas de dire si c'est la base de données qui est HS ou s'il n'y a plus d'espace disque ;
    • les logs permettent de voir quel est le problème réel, mais trop tard.

    Hospital est un framework qui permet:

    • d’écrire des tests avec des assertions comme pour les tests automatiques ;
    • de faire des assertions sur l'application vue de l’intérieur comme une boîte blanche. Il est ainsi possible de tester la connectivité à la base de données ;
    • et de collaborer avec les outils existants comme les outils de supervision. Il existe par exemple un exécutable en ligne de commande qu'un outil de supervision est capable de lancer.

    AnyBlok a retenu notre attention car ses concepts ressemblent à ceux de CubicWeb et les deux projets pourraient s'enrichir mutuellement.

    https://www.logilab.org/file/2100959/raw/pyramid%2Bcubicweb.jpg

    CubicWeb et Pyramid (la vidéo) a été présenté par Christophe de Vienne de Unlish, qui a beaucoup oeuvré pour ce rapprochement. C'est maintenant ce qui est utilisé à Logilab.

    Coté calcul scientifique

    Pythran est un traducteur de code Python en C++, qui permet de construire un module d'extension optimisé à partir d'un code pur Python enrichi de quelques annotations. Il est destiné à un usage scientifique et offre notamment un support partiel de numpy. Il a retenu notre attention et pourrait représenter une alternative intéressante à cython pour certains de nos développements. Son auteur est un partisan de la programmation déclarative: on doit écrire ce que l'on veut obtenir et non pas comment l'obtenir. C'est au compilateur ou à un traducteur de code comme pythran de trouver alors la meilleure façon d'obtenir le résultat décrit. Une partie des améliorations de Pythran est aujourd'hui financée via Logilab grâce au projet OpenDreamKit.

    Conclusion

    https://pbs.twimg.com/media/CRg1lPfXAAAxaWE.jpg:large

    Merci aux organisateurs et à l'EISTI de Pau pour l’accueil. À l'année prochaine pour une nouvelle édition de pyconfr.

    Article rédigé à 3 mains par Yann Voté, Laura Médioni et Arthur Lutz


  • Meetup debian Nantes octobre 2015

    2015/10/23 by Arthur Lutz

    Hier soir, nous nous sommes réunis entre utilisateurs et aficionados de Debian à la cantine numérique de Nantes. Une trentaine de personnes ont répondu présents à l'appel. Damien Raude-Morvan a introduit la soirée, suivi de Thomas Vincent qui nous a présenté le statut de développeur Debian non uploader en invitant les personnes présentes à participer à Debian sans forcément mettre les mains dans le paquet. Lunar a ensuite présenté les travaux sur la compilation reproductible.

    //www.logilab.org/file/2269692/raw/debian_nantes.png

    J'ai présenté rapidement l'utilisation de Salt pour gérer de nombreux systèmes Debian (slides html, slideshare), en appuyant notamment sur l'utilisation du bus d'évènements fourni par salt (scheduler, orchestration, reactor).

    La dynamique des meetups Debian à Nantes est donc (re)lancée avec un objectif de se réunir tous les deux mois. À suivre donc (notamment sur le pad d'organisation).


  • Retour sur le hackaton Code_TYMPAN

    2015/10/14 by Laura Médioni
    https://www.logilab.org/file/2337488/raw/tympan-hackathon.png

    Logilab était présent au hackaton Code_TYMPAN des 5 et 6 octobre 2015, organisé par EDF dans les locaux d'af83 . L'objectif : réunir des développeurs et des experts en acoustique pour imaginer et maquetter de nouvelles fonctionnalités pour Code_TYMPAN.

    http://chercheurs.edf.com/fichiers/fckeditor/Commun/Innovation/logiciels/salome/Logo-Code_TYMPAN_2.jpg

    Cet évènement a été rendu possible par les travaux importants que nous avons conduit sur l'architecture de Code_TYMPAN au cours de ces deux dernières années. En effet, Code_TYMPAN dispose maintenant d'une interface utilisateur développée en Python, ce qui permet à quelqu'un ayant peu de connaissances en développement logiciel d'écrire des scripts de pilotage de simulations acoustiques, ou d'enrichir l'API... En peu de temps et tout en bénéficiant de l'écosystème Python qui facilite l'écriture de post-traitements (numpy, matplotlib, etc.).

    http://www.code-tympan.org/images/CodeIndustriel2.JPG

    Lundi matin, après un petit déjeuner permettant à la vingtaine de participants de faire connaissance, 3 groupes ont été formés autour d'un sujet général tel que "l'acoustique intérieure" ou "les sources acoustiques en mouvement". Le premier objectif de la matinée: brainstormer afin de choisir une ou deux fonctionnalités à prototyper ou implémenter au cours du hackaton.

    Un premier stand-up meeting en milieu de matinée a permis de faire le point sur les différentes idées, puis un cycle de développement/restitution a été conduit jusqu'au lendemain après-midi. Chaque restitution fournissait l'occasion d'échanger avec les membres des autres groupes, d'exposer des problèmes, de recueillir des solutions ou de nouvelles idées. Une restitution finale avec démonstrations a conclu la seconde journée.

    Dans le groupe où était présent Logilab, plusieurs idées ont été abordées:

    • Déplacer des sources au cours de la simulation acoustique, afin de pouvoir tracer l'évolution du bruit en fonction de la distance de la source au récepteur (exemple: cas du décollage d'un avion dans un aéroport). Pistes pour la suite: prendre en compte l'accélération et la décélération.
    • Disposer d'éléments de modélisation de formes plus complexes que de simple cubes, nécessaire pour une simulation au plus proche de la réalité urbaine, où les bâtiments ont souvent une forme irrégulière. Par exemple, ajouter des écrans à casquette (forme en T).
    • Rendre possible la création d'une directivité pour une source depuis l'API, afin de pouvoir modéliser des sources possédant des directivités différentes sur une même surface (exemple de la pale d'éolienne).

    Les autres groupes ont travaillé respectivement sur :

    • les calculs paramétriques et de sensibilité,
    • un démonstrateur d'acoustique intérieure basé sur des lancers de rayon et une modélisation acoustique simple codée directement en Python.
    http://www.code-tympan.org/images/CodeIndustriel.JPG

    Cet évènement a été positif à bien des égards. Outre le fait que c'était un moment très convivial, il a permis aux principaux développeurs de Code_TYMPAN (EDF et Logilab) d'échanger directement avec les utilisateurs et de recueillir leurs besoins. Ce hackaton nous a donné des pistes d'amélioration de l'API, et a mis en évidence la nécessité de renforcer l'aide à la mise en place de l'environnement sous Windows. Ce hackaton a été par ailleurs l'occasion de mettre en contact des gens de différents domaines d'activité qui ont un même type de besoin. Les différents participants ont ainsi pu avoir un aperçu des nombreuses applications possibles de Code_TYMPAN: bruit d'installations nucléaires, bruit intérieur, bruit éolien, bruit routier, bruit aéroportuaire, chantiers en milieu urbain, etc.

    Enfin, chaque participant est reparti avec Code_TYMPAN sur son poste, installé et fonctionnel, ainsi que l'environnement nécessaire à l'exécution de scripts Python. Il n'y a plus qu'à !


  • Nous allons à PyConFR 2015 à Pau

    2015/10/13 by Arthur Lutz

    Nous allons avec une partie de l'équipe de l'agence Toulousaine de Logilab, participer à la conférence annuelle France sur le langage python : PyConFr. Nous avions appris plein de choses l'année dernière, et partagé via une série d'articles de blogs (1, 2, 3).

    https://www.logilab.org/file/2100950/raw/banner.png

    Quatre présentations à noter dans votre planning si vous avez la chance de pouvoir venir (la conférence est gratuite et accueillante). Les descriptions détaillées sont au bout des liens :

    https://www.logilab.org/file/2100959/raw/pyramid%2Bcubicweb.jpg https://www.logilab.org/file/2100965/raw/pybv10b-persp.jpg

    Au plaisir de vous y croiser.


  • WebGL Paris 2015

    2015/10/13 by Florent Cayré

    Hier, Logilab assistait à la journée de conférence WebGL Paris dans le centre de conférences de Microsoft France.

    https://upload.wikimedia.org/wikipedia/commons/3/39/WebGL_logo.png

    Cette journée était riche de présentations variées par le public visé : scientifiques, artistes, développeurs, équipes mixtes graphistes/ développeurs. J'ai apprécié le format assez long de ces présentations, qui permet d'approfondir plus qu'à l'habitude. Les présentateurs ont profité de ce temps soit pour illustrer leur démarche artistique, soit pour démontrer l'utilisation en direct des technologies proposées, ce qui rend les présentations à la fois plus vivantes et plus motivantes pour les techniciens que nous sommes car plus rapides à mettre en oeuvre.

    Logilab s'intéresse depuis plusieurs années à WebGL (et autres API HTML5 avancées, comme WebAudio), ayant réalisé plusieurs démonstrateurs utilisant cette technologie, notamment une interface de Web pour Code_TYMPAN basée sur CubicWeb, ou encore un outil de visualisation de maillages pour Simulagora. Nous souhaitions lors de cette conférence aller plus loin en recherchant :

    • des manières originales de présenter des données, par exemple celles tirées de l'application derrière http://data.bnf.fr, développée par Logilab avec CubicWeb ;
    • à déporter des calculs du serveur vers le navigateur en utilisant le GPU via le langage GLSL, ce qui pourrait conduire à des solutions innovantes pour nos applications scientifiques.
    http://data.bnf.fr/data/logo-data.gif http://code-tympan.org/images/sampledata/fruitshop/Logo%20Code_TYMPAN_%20transparence_medium0.png

    Au travers de ce prisme, les présentations qui nous ont le plus intéressés lors de cette journée WebGL Paris sont les suivantes :

    • Réseaux de neurones : intéressante entrée en matière par Xavier Bourry sur la thématique du calcul dans le navigateur, même si on aurait aimé y voir un peu plus de code ; son site http://webglacademy.com/ est cependant une source d'information très intéressante sur le sujet, par exemple la leçon sur la résolution des équations de Saint-Venant régissant les écoulements de fluide à surface libre ;
    • WebVR : dans cette présentation, Jean-marc Le Roux a surtout présenté les outils de développement de la plateforme Minko, en particulier l'extension créée pour Blender permettant aux graphistes 3D d'aller plus loin dans le processus de création en intégrant eux-mêmes des scripts dédiés à différents effets 3D (animation de forme, environnement lumineux, etc.) dans l'application Web, en temps réel ; il a finalement assez peu été question de réalité virtuelle, bien que l'intérêt de cette API, identique dans Firefox et Chrome, mais encore considérée comme expérimentale, ait été souligné ;
    • Live coding avec BabylonJS : au cours de cette présentation, David Rousset a notamment montré le tout nouveau BabylonJS playground, qui offre une façon très didactique de se mettre à BabylonJS et de partager du code ;
    • Le raymarching : Rémi Papillié nous a fait une démo live à la fois efficace et instructive de cette technique facile à mettre en place ; cela m'a permis de voir comment écrire et tester visuellement des shaders, et me permettra de me lancer plus facilement dans le développement d'applications scientifiques avec GLSL ; ce champ a l'air finalement assez peu exploré, comme en témoigne le faible nombre d'outils permettant de tester automatiquement du code GLSL : GLSL Unit semble être le seul outil disponible.
    http://download.blender.org/institute/logos/blender-plain.png http://babylonjs.com/Assets/Logo.png

    En conclusion, on a beaucoup apprécié cette journée qui nous a fournit de bonnes pistes techniques et motivés pour continuer à pousser nos clients dans à utiliser WebGL. Merci aux organisateurs et aux présentateurs !


  • Méthodes Agiles et logiciels sûrs

    2015/09/23 by Sylvain Thenault

    J'ai assisté ce mercredi à une journée d'étude sur le thème "agilité et logiciels sûrs". Organisé par Aerospace Valley, il y avait une quarantaine de personnes, à la fois des agilistes expérimentés et des curieux, voir dubitatifs, pour l'essentiel venant des industriels du secteur.

    https://www.logilab.org/file/1625539?vid=download

    C'est Claude Aubry qui s'est chargé de chauffer la salle en posant les fondements de l'agilité en général et de Scrum en particulier. Je ne vais pas m'étendre sur cette présentation rapide, efficace et appréciée, si ce n'est sur les rappels suivants qui me paraissent particulièrement intéressants dans le contexte :

    • l'agilité est une culture avant d'être des processus,
    • cela permet de gérer le décalage entre les plans et la réalité grâce à une boucle de rétroaction courte,
    • c'est fait pour gérer des systèmes complexes et adaptatifs,
    • dans le cadre du développement de logiciel sûr, on prendra notamment soin à :
      • la présence d'experts lors des réunions d'affinage,
      • la définition de fini,
      • montrer l'incertitude.

    Je citerai pour conclure cette introduction la définition de l'Agilité selon Claude :

    "l'agilité est la capacité d'une organisation à fournir tôt et souvent de la valeur, tout en s'adaptant à temps aux changements dans son environnement"
    https://upload.wikimedia.org/wikipedia/commons/1/1a/ST_vs_Gloucester_-_Match_-_23.JPG

    (photo par Pierre Selim, licence CC-By-SA 3.0)

    Gérard Ladier et Jean-Paul Blanquart sont ensuite entrés dans le vif du sujet avec une double-présentation-avec-passe-de-ballon (oui oui, y avait 2 projections simultanées avec 2 projecteurs) sur le sujet des contraintes liées au besoin de certification dans le cadre de l'aéronautique pour Gérard et du spatial pour Jean-Paul.

    En commençant par rappeler que normes et règlements ne sont pas là (que) pour nous embêter mais avant tout pour protéger des parties prenantes qui n'ont pas forcément leur mot à dire dans le cadre de la définition d'un produit. Comme vous et moi dans le cadre d'un nouvel avion par exemple : on nous demande pas notre avis mais on pourrait bien finir par le prendre. Ainsi, ces normes et règlements sont censés fournir un cadre permettant de répondre à un objectif de très haut niveau, aussi simple que "on ne doit pas risquer sa vie en montant dans un avion de ligne".

    Je vais passer sur la plupart des points techniques, si ce n'est pour citer la fameuse DO-178C aéronautique qui est la norme définissant les différents niveaux de conformité qu'un logiciel devra agréer dans le cadre de la certification d'un programme. Apparemment, s'il y en a bien une à connaître c'est celle-ci (et ECSS côté spatial).

    Le point important, c'est que ces normes découpent le projet en phase avec des échéances obligatoires mais sans pour autant y associer de méthode. Notamment le cycle de développement en soi n'est pas normé. Il n'y a donc pas de contre-indications à utiliser des méthodes agiles pour répondre aux exigences de ces normes. Ce qui ne veut pas dire qu'il n'y a pas de résistance au changement des habitudes, et notamment celles des experts...

    Gérard a complété ce numéro de duettistes par une présentation des attentes d'Airbus en manière d'agilité :

    1. changer la manière de développer pour accompagner le passage à un mode de développement incrémental des avions et obtenir une diminution du time-to-market,
    2. diminuer les coûts liés aux défauts pour permettre l'augmentation des taux de productions,
    3. améliorer la gestion du risque et de la complexité afin de faire face à l'augmentation des coût de développement

    Donc si on en croit cette présentation, Airbus constate qu'il faut apprendre à travailler différemment, ils sont prêts à tester l'agilité sur des sous-systèmes (trop disruptif sur un système complet, faut pas pousser !) et sont même en attente de challenges de la part de leur partenaires. À suivre !

    https://www.logilab.org/file/1616201?vid=download

    (photo par pixabay, licence CC0)

    L'après-midi, on est reparti sur les chapeaux de roue avec une présentation d'Emmanuel Chenu de Thales Avionics, porteur d'un message massue : "on l'a fait (et on en est content)". Tout part du constat des problèmes liés à l'intégration "big-bang" entre logiciels ou entre logiciel et matériel, mais aussi du fait que mener les activités liées à la certification tardivement et en gros lots :

    • ne réduit pas la complexité,
    • ne permet pas de corriger tôt les pratiques,
    • génère des activités peu efficaces et pas fiables,
    • empire avec l'avancée dans le projet.

    Ces choix ne sont évidemment pas un hasard, ils s'expliquent en particulier par le besoin de versions anticipées non certifiées, ou encore par les échéances des audits qui collent au cycle en V. Malgré tout cela, ils ont donc tenté d'appliquer l'agilité aux développements d'une centrale inertielle pour l'A350 (ADIRU de son petit nom). Ce projet, qui doit répondre au plus haut niveau de la norme DO-178C, est spécifié par plusieurs milliers d'exigences et est constitué au final de plus de 500 000 lignes de code spécifiques. Et il semblerait qu'à l'issue du projet, tout le monde était content :

    • l'avionneur, car il a eu plusieurs livraisons intermédiaires sans régressions et avec globalement moins de défauts (environ 0.15 / kLOC, soit un facteur 100 par rapport aux taux habituels d'après Emmanuel),
    • le service qualité, car il a des retours rapides, globalement moins de soucis et qu'il apprécie la motivation de l'équipe, à la fois à développer et à améliorer son process,
    • l'autorité de certification, qui a été impressionné par le respect des exigences du produit.

    Et vu le deuxième point, on peut raisonnablement penser que l'équipe Thales était contente aussi !

    Les enseignements tirés par Thales et identifiés comme des savoir-faire critiques sont :

    • "produit potentiellement livrable" = le logiciel accompagné de tous les artefacts qui vont avec (notamment ceux nécessaires pour la certification des features développées),
    • l'importance en premier lieu des pratiques techniques:
      • architecture objet
      • test de couverture automatisés
      • intégration continue
      • safe delivery
      • stop the line
      • design by contract
      • qualimétrie
    • il est indispensable d'avoir une gestion de configuration très rigoureuse, notamment en utilisant du versionnement pour les exigences comme pour le code,
    • il faut réorganiser les revues pour ne pas coller au cycle en V, et décrire les itérations et incréments dans les plans.

    Évidemment, comme toujours en développement agile mais encore plus ici : la qualité n'est pas une variable d'ajustement. Et le processus dans son ensemble est suivi par un certain nombre d'indicateurs dont :

    • une mesure "qualité" sur le long terme (somme de critères évolutifs),
    • la couverture des tests,
    • le nombre d'exigences satisfaites.

    Au final, l'avionneur peut s'appuyer sur les versions intermédiaires pour développer d'autres parties de manière incrémentale, il a une mesure plus objective de l'avancement et il obtient une baisse significative des défauts résiduels et de l'impact des changements de priorité. Surtout, Thales démontre ici que l'agilité et la certification DO-178C ne sont pas incompatibles, bien au contraire.

    https://upload.wikimedia.org/wikipedia/commons/thumb/8/8c/Airbus_A350-900_XWB_Airbus_Industries_%28AIB%29_MSN_001_-_F-WXWB_%2810223175703%29.jpg/640px-Airbus_A350-900_XWB_Airbus_Industries_%28AIB%29_MSN_001_-_F-WXWB_%2810223175703%29.jpg

    (photo par Laurent Errera, licence CC-By-SA 2.0)

    La dernière présentation de l'après-midi était celle de Vincent Meunier (SII), mais je dois avouer que mon attention était déjà sévèrement entamée et que le fait qu'il y ait pas mal de recouvrement avec les présentations précédentes l'a achevée. Je me contenterai donc des points suivants que j'ai relevés :

    • il faut coopérer avec tout le monde, y compris les autorités,
    • ne surtout pas retarder les éléments risqués,
    • tester dans un sprint les processus ou les outils dont on doute,
    • adapter le processus global,
    • laisser l'équipe suggérer les améliorations.

    L'après-midi s'est terminée par une séance de brainstorming autour des points à améliorer ou des actions à mener afin d'étendre l'usage de l'agilité dans le contexte de logiciels sûrs. De nombreuses idées ont été soulevés par l'ensemble de l'audience, visiblement intéressée par le sujet. Au point que le pôle Aerospace Valley semble prêt à creuser encore le sujet via un groupe de discussion.

    J'ai de mon côté été agréablement surpris de ce que j'ai vu et entendu. Arrivant avec un a priori négatif sur la relation du milieu l'aéronautique (et en particulier d'Airbus) vis-à-vis de l'agilité, cette journée me fait penser que c'est possible, au moins localement ! Quant au temps qu'il faudra pour faire bouger les lignes, l'avenir nous le dira - mais ça va être long.

    En tout cas merci à Aerospace Valley et en particulier à Gérard Ladier pour cette journée, ainsi qu'à l'ensemble des intervenants qui étaient tous de grande qualité.


  • Exemple de "contrat agile" mis en place entre Logilab et ses clients

    2015/06/18 by Sylvain Thenault

    Dans la mesure du possible, nous essayons de travailler avec nos clients en mode agile. Bon, c'est pas toujours évident, ça ne s'applique pas à tout le monde, mais ce n'est pas le sujet de ce billet. Supposons donc que vous ayez un client déjà initié au sujet et souhaitant fonctionner de cette manière avec vous (si si ça peut arriver !).

    Même dans ce cas, il reste à préciser un certain nombre de points qui vont définir plus précisément les processus et interactions, comme par exemple la durée des itérations, le ou les environnements de test / production et autres manières d'utiliser les outils de suivis. C'est précisément l'objet de ce qu'on appelle le contrat agile, dont voici un exemple qu'il me semble utile de partager avec vous (miroir sur slideshare).

    https://www.logilab.org/file/294043/raw/handshake.jpg

    (photo by Julia Taylor licence CC BY-NC-ND )

    Cet exemple a été légèrement anonymisé. Il rappelle quelques éléments d'agilité et définit :

    • le cycle de développement (itération, recette, etc)
    • les livrables et environnements
    • le mode de fonctionnement avec notre extranet de suivi (une variante de cette forge)

    Il vous faudra donc de fait l'adapter à votre projet, en collaboration avec votre client. Et évidemment, dans un esprit agile, le faire évoluer au fur et à mesure du temps (dans l'exemple avec notre client, nous en sommes à la 3eme version).

    Les sources sont du HTML qui utilise showr et je n'ai aucun problème à les partager pour ceux qui ça intéresse.

    Enfin merci de me faire part de vos remarques et retours sur ce contrat !


  • BestOfWeb 2015

    2015/06/11 by Adrien Di Mascio

    Nous étions à la journée BestOfWeb 2015 vendredi. Au programme, quelques unes des présentations jugées les plus intéressantes qui avaient été faites lors de différents meetups orientés "web" ces derniers mois.

    http://photos4.meetupstatic.com/photos/event/3/8/3/2/global_434894386.jpeg

    Même si j'aurais pu me passer des nombreuses interventions des sponsors et si toutes les présentations n'ont pas retenu mon attention, j'ai dans l'ensemble bien apprécié la journée. Voilà en particulier ce que je retiens :

    • angular n'a plus beaucoup de défenseurs, ou alors ils crient moins fort que les autres. De notre côté, après l'avoir utilisé pour construire quelques applications, la mauvaise documentation, la difficulté à conserver l'application maintenable et le fait qu'angular 2 — qui aura certainement plein de qualités — ne laisse pas de perspective de migration simple du code nous ont amenés à préférer des bibliothèques plus simples comme Backbone ;

    • Microsoft continue à contribuer du code libre et poursuit sa reconquête des développeurs perdus ;

    • j'aurais bien aimé voir Hydra mentionné dans la présentation REST,

    • j'étais resté sur l'utilisation de Accept-Ranges et Range dans le cadre de contenus binaires et je découvre (!) que ça semble être une pratique courante de les utiliser pour la pagination dans les API REST. À utiliser dans CubicWeb ?

    • CSS Grid Layout n'a pas l'air parti pour être utilisable avant un petit moment ;

    • l'an dernier, dans le cadre d'une collaboration avec l'itemm, nous avions fait de l'acquisition audio dans le navigateur. Nous testions la justesse d'instruments à vents et affichions les instruments en 3D dans le navigateur. Je me souviens qu'il fallait utiliser les nightly builds de chrome pour que ça fonctionne. Mais la présentation de l'ircam a montré que l'api Web Audio décollait vraiment. Ils ont fait des démonstrations de mixage en direct et on est passé à deux doigts de faire faire du sound painting à l'assemblée à coups de téléphones portables et websockets. Leur dépôt GitHub vaut le détour ;

      /file/293356/raw
    • RxJS et ses cousins BaconJS et KefirJS permettent d'écrire des traitements de flux d'information assez simplement à partir d'événements, de promesses et de plein d'autres choses.

    Et CubicWeb dans tout ça ? Et bien tout ça m'a donné envie de continuer activement le travail entamé sur le javascript utilisé dans CubicWeb. J'aimerais notamment qu'on puisse écrire de l'ES 6, qu'en mode debug, les fichiers soient transpilés à coups de babel (-- watch) et qu'on transpile également à la construction des paquets. On pourrait par la même occasion définir la liste des fonctionnalités "futures" qu'on s'autorise à utiliser dans le cœur de CubicWeb et pour lesquelles CubicWeb fournirait des polyfills si besoin (promesses, fetch, fileAPI, etc.).

    Pour conclure, félicitations aux organisateurs pour avoir su trouver une autre salle à la dernière minute et pour la qualité de la journée dans son ensemble. Sans doute à l'an prochain et pour certains d'entre eux à bientôt à WebGL Paris


  • 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.


  • Retour sur la journée conteneurs dans le cadre de Open Source Innovation Spring

    2015/04/07 by Arthur Lutz

    Logilab a co-organisé la demi-journée sur les conteneurs dans le cadre du Printemps de l'innovation open source (Open Source Innovation Spring). Voici une partie des choses qui y furent dites.

    Open Source Innovation Spring

    AlterWay a commencé par une introduction expliquant pourquoi docker est si hype en ce moment. Quelques bémols ont été placés sur les questions de sécurité et les systèmes de fichiers utilisés par défaut (AUFS n'est pas dans le kernel linux officiel, des alternatives sont à l'étude).

    Une partie de l'écosystème autour de Docker a été mentionné :

    Ensuite Normation a présenté la gestion de configuration et Docker, avec de grandes questions générales sur le déploiement de serveurs, leur durée de vie, leur transformation, etc.

    Logilab & Mozilla

    Logilab a présenté l'utilisation conjointe de Salt Mercurial et Docker pour appliquer les bonnes pratiques du développement logiciel à la gestion d'infrastructures. Les supports de présentation sont sur http://slides.logilab.fr/osis/osis (aussi sur slideshare).

    Normation a ensuite présenté les fondements techniques des conteneurs, à savoir les fonctionnalités du noyau linux qui ont permis leur essor. Petit historique sur les cgroups, avec les idées d'origine sur les processus dans Unix, mais aussi les bonnes idées apportées par Plan 9 (et qui ont ensuite été reprises par Linux). On a vu des choses sur les chroots, les namespaces, fakeroot, ip netns, les informations dans /proc/<pid>/ns, et les systèmes de fichier d'union utilisé par les conteneurs : aufs, unionfs, overlayfs, fuse.

    Intervenants de la journée

    Ensuite deux démonstrations ont été présentées :

    • Utilisation de docker et docker-swarm sur amazon ec2 pour déployer une application html5 : CircleCI lit le dépôt git de l'application, construit l'image Docker et l'ajoute au hub puis pilote docker-swarm pour qu'elle soit déployée.
    • Utilisation de plusieurs plate-formes de cloud (Azure, Numergy, CloudWatt) pour déployer un conteneur docker sur plusieurs clouds en parallèle.

    Deux retours d'expérience par Theodo et Deliverous ont conclu la journée.


  • De retour du raid agile

    2015/03/17 by Sylvain Thenault
    https://www.logilab.org/file/288474?vid=download

    J'ai eu la semaine dernière la chance de participer au raid agile organisé par Pablo et Claudio. Je dis bien une chance car, de mon point de vue, cette formation atypique donne vraiment l'occasion de passer quelques jours loin du quotidienn dans un cadre idyllique et une ambiance sympathique, à réfléchir aux fondements des méthodes agiles. En plus d'y (re)découvrir un tas d'outils et de jeux agiles, c'est l'occasion d'échanger avec tous les participants et de remettre en cause ses pratiques. Bref, une bonne remise à zéro des compteurs. Je ne vous révélerais pas plus l'emploi du temps minuté-mais-aéré des trois jours (vous en saurez plus sur le site), je ne saurais que vous recommander de sauter sur l'occasion de partiper à une prochaine édition du raid !

    Ceci étant dit, revenons-en à l'objet principal de ce billet : ce que j'ai ramené dans ma petite tête pour améliorer nos pratiques à Logilab. Ou en tout cas celle que j'essaie de mettre en place avec mon équipe à Toulouse.

    Une de mes principales problématiques est la suivante : comment adapter une méthode comme Scrum ou un outil comme le kanban dans le cadre d'une petite société de service, où nous avons majoritairement des petits projets, plusieurs en parallèle, développés par une à deux personnes maximum ? La littérature sur le sujet applique systématiquement (à ma connaissance) la méthode à des équipes de développement "produit" avec des phases souvent gérées par des personnes différentes (développeurs, testeurs, intégrateurs, etc.). Ça fait un moment que je tâtonne sur le sujet, d'une manière parfois satisfaisante, parfois frustrante, mais certainement améliorable. Sans prétendre avoir répondu à toutes mes interrogations, une réflexion de Claude m'a donné envie d'améliorer un point en particulier : travailler en équipe, plutôt qu'être une somme d'individus dans un même espace. Le principal changement à conduire consistera donc à faire travailler tous les membres de l'équipe sur tous les projets. Il y aura bien sûr un coût non-négligeable dans la mise en place de chacun sur chaque projet, mais j'espère que cela sera contrebalancé par :

    • la montée en compétence de l'ensemble de l'équipe ("essaimage")
    • moins de spécialisation individuelle, plus de souplesse dans la gestion des projets
    • un renforcement de l'esprit d'équipe

    Pour moi, ça vaut donc le coup de tenter ! Et le compagnon de ce changement sera un autre point qui me pose souvent question : le découpage des besoins du client en user stories (voir features ou epics) et tâches, leur relation avec le kanban qu'on essaie de mettre en place (principalement pour visualiser les tâches de chacun jusqu'ici) et notre extranet de gestion de projet. Jusqu'ici, nous dupliquions plus ou moins l'information, sans vraiment faire ressortir la notion de tâche autrement que dans les discussions informelles. Pour maintenir un rapport coût de gestion / besoin de collaboration et d'indicateurs, on va maintenant essayer de maintenir les histoires dans l'extranet, avec leur estimation, les discussions avec le client et autres (dépendance, relation aux features, etc.), tout en ayant sur le kanban les tâches qui en découlent. Ceci devrait notamment permettre de mieux échanger sur les implémentations des différentes histoires en amont, voire de permettre à plusieurs personnes de travailler sur la même histoire. Et ainsi de rendre le kanban plus au centre de notre gestion quotidienne en diminuant sa granularité.

    Ces deux points sont les gros morceaux qu'il va falloir digérer dans les prochains mois. Parmi les autres points abordés ou évoqués pendant la formation et ramenés en stock, il y a :

    • faire un delegation board avec l'équipe à Toulouse et peut-être aussi à l'échelle de Logilab entre les équipes de direction et de développement, voire au sein de l'équipe de direction ;
    • ne pas oublier de faire fixer l'heure sur l'horloge de Cohn à nos clients qui jouent le jeu de l'agilité (ils ne seront jamais assez nombreux) ;
    • faire plus de rétrospectives, sans hésiter à en essayer différentes formes ;
    • à l'occasion, réessayer un impact mapping, l'exercice le plus délicat que nous ayons abordé ;
    • rappeler que si on fait des journées "compactes" à Toulouse, il ne faut pas oublier de maintenir un rythme soutenable. Voir acheter un canapé ou un siège confortable pour les amateurs de power nap (merci Pierre-Jean dont la pratique décomplexée est rafraichissante !) ;
    • enfin creuser les core protocols et le business value game dès que possible, voire réfléchir au #noSlides pour nos formations techniques.

    Voilà, y a encore d'autres restes parmi les outils et idées discutés, mais je pense avoir cité ici l'essentiel et ça promet déja des impacts non négligeables. J'accueillerais avec plaisir vos remarques ou idées sur les points ci-dessus. Et avec un peu de chance j'aurais même le courage de faire un billet pour raconter ces différentes expériences ! En tout cas, encore un grand merci à Pablo et Claudio ainsi qu'à tous les participants de ce raid du changement.


  • PyconFR 2014 : jour 1, bus de communication, packaging et fin

    2014/11/04 by Arthur Lutz

    Suite à :

    XBUS

    Florent Aide nous a présenté son projet XBUS, un bus de communication pour les applications. L'idée est de gérer l'historique : pour faire parler des applications métier entre elles, on les connecte toutes au même bus. Dans certains cas, notamment quand la sécurité des données est en jeux, l'application qui traite le message renvoie un accusé de réception et de traitement (ACK).

    Côté technique, il s'agit de :

    • un cœur écrit en Go
    • zmq pour la communication
    • Python pour la logique

    Lors des questions un projet similaire a été mentionné : autobahn. Le projet XBUS est libre et publié sur bitbucket.

    Comment le packaging m'a simplifié la vie

    Étant donné qu'à Logilab, nous avons des avis assez arrêté sur les questions de packaging, je suis allé voir cette conférence.

    Xavier Ordoquy nous a présenté en détail virtualenv (pyvenv directement dans python à partir de 3.4) ainsi que l'outil pip.

    Historiquement pypi a été instable, mais la situation s'est améliorée depuis qu'il est sur un CDN. Il y a un travail en cours sur la sécurité (vérification d'intégrité, ssl obligatoire etc). devpi permet d'avoir un pypi en interne comme cache, mais aussi comme système de "staging" avant de publier sur le pypi "officiel".

    Selon Xavier, la guerre des distutils, python.packaging, distutils2, distribute, etc est finie. Il faut à présent utiliser setuptools et le connaître sur le bouts des doigts. Xavier nous recommande de copier un setup.py pour démarrer nos projets, par exemple celui de sentry.

    Côté numéro de version, il faut aller lire la PEP440 Version Identification and Dependency Specification.

    extra_requires permet de faire : pip install sentry[postgres] qui installe sentry mais aussi les dépendances pour le faire marcher avec PostgreSQL.

    Côté packaging, il va falloir selon Christophe apprendre à utiliser wheel et stevedore (code).

    Lors des questions, un membre du public mentionne le projet diecutter (docs, pypi).

    Support de présentation : https://speakerdeck.com/xordoquy/packaging-pratique-fr

    Autres liens collectés

    • Pour travailler sur les docstrings d'un projet python, pyment peut être utile.
    • fedmsg est un bus de communication utilisé chez fedora/redhat pour un grand nombre d'applications, il y a probablement de bonnes choses dedans. Il y a un début de travail sur un bus similaire chez debian

    Prochain épisode

    Prochain épisode: jour 2


  • PyconFR 2014 : jour 1, frameworks web et gestion de source

    2014/11/04 by Arthur Lutz

    Suite de pyconfr 2014 jour 1 épisode 1.

    Performance des frameworks web : Python vs the world

    Ronan Amicel nous a présenté le travail de benchmark publié par TechEmpower. Ces tests et résultats sont forcement faux et biaisés, mais le code source des tests est publié en libre et il est donc possible d'apporter des corrections via le projet sur github

    Pour l'instant, Python3 serait plus lent que Python2, mais on peut espérer que Python3 rattrape son retard, puisqu'il est toujours développé. La comparaison avec pypy est surprenante, celui-ci est bien plus lent, l'hypothèse étant qu'il est ralenti lorsqu'il parle au driver mysql. En revanche, pour le test pypy + tornado, les performances peuvent être meilleures que nodejs car tornado est écrit en pur python il peut être optimisé par pypy.

    Dans le comparatif entre python et php, un acteur surprenant est phalcon qui a pris le parti de tout coder en C (plutôt qu'une partie seulement comme on peut le trouver dans nombre de projets python).

    Support de présentation : https://speakerdeck.com/ronnix/performance-des-frameworks-web-python-vs-the-world-v1-dot-1

    CubicWeb - Vos données ont du sens

    Nous attendions avec impatience cette présentation, et Christophe de Vienne a très bien présenté CubicWeb, le framework web dont Logilab est à l'origine.

    https://www.logilab.org/file/269991/raw/logo-cubicweb.png

    Après une courte introduction aux concepts du web sémantique (les URIS, les relations, le Linked Data), il a appuyé sur la nécéssité de donner du sens aux données que l'on stoque dans nos applications. Il a expliqué la finesse des réglages dans le moteur de permissions de CubicWeb.

    Il a expliqué certaines fonctionnalités intéressantes selon lui dans Cubicweb :

    • les hooks: équivalent des procédures stockées déclenchées par des triggers, ils sont écrits en Python et permettent de modifier des données en cascades, implémenter des règle de gestion ou générer des notifications.
    • les adaptateurs : permettent de maximiser la réutilisation de code en adaptant une entité à une nouvelle interface

    Selon Christophe, CubicWeb permet de développer une "base de donnée métier" strictement structurée, mais restant souple. Il a expliqué que l'interface par défaut n'est pas très sexy, mais qu'elle est néanmoins fonctionnelle comme backend d'édition.

    Une petite introduction aux cubes qui sont les "plugins" ou les "extensions" dans le monde CubicWeb, ils contiennent :

    • un schéma
    • du code métier
    • des vues
    • des contrôleurs

    Pour manipuler les données, CubicWeb utilise RQL, qui a été inventé avant SPARQL (langage de requête du web sémantique) et est plus pragmatique et lisible. Une fonctionnalité notable de RQL : plus besoin d'écrire des jointures SQL !

    Finalement Christophe a conclu en présentant le mariage de Pyramid et Cubicweb. Selon lui, en regardant dedans, ils ont des philosophies communes. Le code permettant de développer une application Pyramid sur une base CubicWeb est publié sur la forge de CubicWeb. Christophe a aussi expliqué qu'il pousse des modifications pour que CubicWeb soit plus accessible aux développeurs habitués aux modes de développement "à la python".

    Support de présentation : https://dl.dropboxusercontent.com/u/36590471/pyconfr-2014-pres-cubicweb/index.html

    La gestion de version, ce problème tellement simple…

    Pierre-Yves David (marmoute) nous a concocté un petit panorama des problèmes traités par les gestionnaires de source, avec des anecdotes de problèmes non-triviaux et quelques rappels historiques sur notre "science" informatique (merci les encodages!) Pierre-Yves s'est concentré sur les systèmes de gestion de version de "nouvelle génération", les outils décentralisés (hg, git, bzr). Forcément, étant donné qu'il travaille sur mercurial (et oui, celui écrit en python) il s'est concentré sur celui-là.

    http://mercurial.selenic.com/images/mercurial-logo.png

    Quand il travaillait chez Logilab, Pierre-Yves a notamment rajouté à Mercurial la notion de changeset obsolete et de phase pour faciliter la revue de code et le travail en équipe.

    Manipuler son code python avec RedBaron

    baron et RedBaron sont des projets assez prometteurs (et assez dingues) de manipulation de code en utilisant du code (plutôt que des éditeurs).

    Laurent Peuch est revenu sur les outils historiques du domaine : rope qui a pris la suite de bicycle repair man. Il y a aussi pyfmt par le même auteur, et autopep8 écrit par d'autres.

    Un exemple qui m'a parlé : ajouter @profile sur toutes les fonctions d'un script devient faisable en 3 lignes de python, et inversement pour les enlever. À suivre...

    Support de présentation : https://psycojoker.github.io/pyconfr-redbaron/presentation.html

    Prochain épisode

    Prochain épisode: jour 1, bus de communication, packaging et fin


  • PyconFR 2014 : jour 1, BDD, postgresql et asyncio

    2014/11/03 by Arthur Lutz

    J'ai eu le plaisir de participer à la conférence PyconFR 2014, voici quelques notes sur les présentations auxquelles j'ai pu assister. Étant donné la longueur, je vais publier sous forme de plusieurs billets de blog.

    http://www.pycon.fr/2014_static/pyconfr/images/banner.png

    BDD avec Behave

    Le Behaviour Driven Develpment en Python peut se faire avec behave. Dans un premier temps on décrit en language "naturel" le test. Dans un deuxième temps on implémente les tests unitaires pour faire le lien avec la description behave, et on met les chaines de caractères dans un decorateur @given, puis @when puis @then.

    Les scenarios behave sont utiles pour le dévelopement, pour la documentation, pour la formation des nouveaux arrivants et même pour faciliter la supervision des applications en production.

    Les diapos de la présentation sont disponible sur slideshare.

    Python + PostgreSQL

    Stéphane Wirtle nous a présenté comment les relations étroites entre le monde de Python et celui de PostgreSQL.

    https://avatars1.githubusercontent.com/u/2947270?v=2&s=400

    Points à noter :

    • FDW : Foreign Data Wrapper, dont voici une liste sur le wiki de PostgreSQL
    • PL (Procedure Language) : PL/C, PL/Python, PL/v8, etc. pour étendre sa base de donnée. Les procedure language SQL sont par défault "trusted", les autres ne sont pas trusted par défaut. Dans CubicWeb, nous utilisons PL/Python pour la recherche plein texte et la lemmatisation du texte.

    Pour ceux qui souhaiteraient essayer un ORM, Stéphane Wirtle conseille Peewee ORM.

    Pour les migrations de schema SQLalchemy, Stéphane Wirtle nous conseille Alembic.

    Parfois un ORM peut générer beaucoup de requêtes SQL et il y a de la place pour une optimisation en tapant directement du SQL. Pour évaluer la surcharge dûe à l'ORM, on peut utiliser pgBadger.

    Support de présentation : https://speakerdeck.com/matrixise/python-and-postgresql-a-wonderful-wedding/

    Un serveur fiable avec python 3.4

    Après une petite introduction aux principes de concurrence, Martin Richard nous a présenté un retour d'expérience sur l'utilisation du module asyncio introduit dans python 3.4. Il permet de ne plus avoir à utiliser twisted ou gevent.

    Les ressources et bibliothèques qui utilisent asyncio sont recensées sur http://asyncio.org/

    objgraph permet de d'analyser des structures de données Python pour identifier des fuites memoire.

    memoryview introduit dans python3.4 permet de faire "référence" à une structure de données sans la copier, ce qui peut être très pratique mais rend complexe la gestion de code.

    Martin a utilisé @lru_cache pour mettre en cache les resultats d'un calcul en utilisant la politique de cache "Least Recently Used (LRU)".

    Support de présentation : http://marti.us/t/pyconfr-2014/


  • PyconFR 2014 - on y va !

    2014/10/24 by Arthur Lutz

    Pycon.fr est l’événement annuel qui rassemble les utilisateurs et développeurs Python en France, c'est une conférence organisée par l'AFPY (L'Association Francophone Python). Elle se déroulera cette année sur 4 jours à Lyon : 2 jours de conférences, 2 jours de sprints.

    http://www.pycon.fr/2014_static/pyconfr/images/banner.png

    Nous serons présents à PyconFR les samedi et dimanche pour y voir les présentation nombreuses et prometteuses. Nous assisterons en particulier à deux présentations qui sont liés à l'activité de Logilab :

    On espère vous y croiser. Si tout va bien, nous prendrons le temps de faire un compte rendu de ce qui a retenu notre attention lors de la conférence.


  • Petit compte rendu du meetup postgresql d'octobre 2014

    2014/10/09 by Arthur Lutz

    Hier soir, je suis allé au Meetup PostgreSQL intitulé "DBA et Développeurs enfin réunis". Après quelques bières et pizza (c'est la tradition de le faire dans ce sens), nous avons écouté 4 présentations autour de PostgreSQL après une courte introduction de Dimitri Fontaine et des sponsors (Mozilla et Novapost).

    http://www.logilab.org/file/266939/raw/BzcR8UOIQAAdFMh.jpg

    Jean-Gérard Pailloncy nous a parlé d'aggrégation temporelle sous contrainte d'IOPS (page wikipedia pour IOPS, au cas où). Malgré le temps court de présentation, c'était une synthèse très bien déroulée d'un projet avec des flux de données ambitieux pour des plateformes "entrée de gamme". Quelques "petites" astuces que chacun pourrait appliquer à ses projets.

    Flavio Henrique Araque Gurgel nous a parlé du partitionnement de tables et des mythes qui entourent ce sujet. Dans quels cas dois-je partionner ? Beaucoup de cas de figure sont possibles, les métriques qui permettent de prendre ce genre de décisions sont nombreuses et nécessitent une bonne compréhension du fonctionnement interne des bases de données Postgresql. Il s'agissait principalement d'amener les praticiens de postgresql à se poser les bonnes questions lors de la conception de leur base de données.

    Thomas Reiss et Julien Rouhaud nous ont présenté POWA (PostgreSQL Workload Analyzer). Il s'agit d'une extension C pour postgresql (à partir de 9.3) et une interface en Perl and Mojolicious. Un projet prometteur (bien que l'on puisse être supris qu'il soit écrit en Perl) pour maîtriser les performances de sa base de données postgresql.

    http://www.logilab.org/file/266940/raw/safe.png

    Enfin, Dimitri Fontaine a prêché la bonne parole pour rapprocher les développeurs des administrateurs de bases de données. L'idée était de faire penser aux développeurs que le SQL dans leur code est du code, pas juste des chaînes de caractères. Quelques exemples autour des "window functions" et de "common table expressions" plus tard, on espère que les développeurs feront une partie de leurs calculs directement dans PostgreSQL plutôt que dans leur application (en évitant de balader des tonnes de données entre les deux). Petit conseil : il est recommandé de rajouter des commentaires dans les requêtes SQL. "SQL c'est un language de programmation en vrai."

    Les slides devraient être publiés sous peu sur le groupe meetup, que vous pouvez rejoindre pour être informés du prochain meetup. Update : slides publiés sur : https://wiki.postgresql.org/wiki/PostgreSQL_Meetup_Paris_2014_Sept

    À Logilab nous utilisons beaucoup Postgresql que ce soit sur des projets clients (données métier, GIS, etc.) mais aussi extensivement dans CubicWeb, framework web en python orienté web sémantique.

    Le format de 20 minutes par présentation est pas mal pour toucher rapidement à un grand nombre de sujets, du coup souvent il s'agit de pistes que chacun doit ensuite explorer. Les meetups sont toujours aussi sympathiques et accueillants.


  • Lancement du blog de la communauté salt francaise

    2014/09/25 by Arthur Lutz

    La communauté salt est bien vivante. Suite au meetup de septembre, elle s'est doté d'un petit site web :

    http://salt-fr.afpy.org
    http://www.logilab.org/file/266455/raw/Screenshot%20from%202014-09-25%2014%3A32%3A27.png

    Nous éspérons pouvoir continuer à rassembler les enthousiasmes autour de salt lors de ces rendez-vous tous les 2 mois. J'ai donc publié le compte rendu du meetup sur ce site.


  • Logilab à EuroSciPy 2014

    2014/09/02 by Florent Cayré
    http://www.euroscipy.org/2014/site_media/static/symposion/img/logo.png

    Logilab était présent à EuroSciPy2014 à Cambridge la semaine dernière, à la fois pour suivre les travaux de la communauté scientifique, et pour y présenter deux posters.

    Performances

    Il y a encore beaucoup été question de performances, au travers de tutoriels et de conférences de grande qualité :

    • une Keynote de Steven G. Johnson expliquant comment le langage Julia, de haut niveau et à typage dynamique parvient à atteindre des performances dignes du C et du Fortran dans le domaine numérique : le langage a été conçu pour être compilé efficacement avec un jit (just-in-time compiler) basé sur LLVM , en veillant à rendre possible l'inférence des types du maximum de variables intermédiaires et des retours des fonctions à partir des types d'entrée, connus au moment de leur exécution. L'interfaçage bidirectionnel avec le Python semble très simple et efficace à mettre en place.
    • un tutoriel de Ian Ozswald très bien construit, mettant bien en avant la démarche d'optimisation d'un code en démarrant par le profiling (cf. aussi notre article précédent sur le sujet). Les différentes solutions disponibles sont ensuite analysées, en montrant les avantages et inconvénients de chacune (Cython, Numba, Pythran, Pypy).
    • l'histoire du travail d'optimisation des forêts d'arbres décisionnels (random forests) dans scikit-learn, qui montre à quel point il est important de partir d'une base de code saine et aussi simple que possible avant de chercher à optimiser. Cet algorithme a été entièrement ré-écrit de façon itérative, conduisant au final à l'une des implémentations les plus rapides (sinon la plus rapide), tous langages confondus. Pour parvenir à ce résultat des formulations adroites de différentes parties de l'algorithme ont été utilisées puis optimisées (via Cython, une ré-organisation des données pour améliorer la contiguïté en mémoire et du multi-threading avec libération du GIL notamment).
    • la présentation de Firedrake, un framework de résolution d'équations différentielles par la méthode des éléments finis, qui utilise une partie de FEniCS (son API de description des équations et des éléments finis à utiliser) et la librairie PyOP2 pour assembler en parallèle les matrices et résoudre les systèmes d'équations sur GPU comme sur CPU.
    • la présentation par Jérôme Kieffer et Giannis Ashiotis de l'ESRF de l'optimisation de traitements d'images issues de caméras à rayons X haute résolution débitant 800Mo/s de données en utilisant Cython et du calcul sur GPU.

    Autres sujets remarqués

    D'autres sujets que je vous laisse découvrir plus en détails sur le site d'EuroSciPy2014 prouvent que la communauté européenne du Python scientifique est dynamique. Parmi eux :

    • un tutoriel très bien fait d'Olivier Grisel et Gaël Varoquaux sur l'analyse prédictive avec scikit-learn et Pandas.
    • une belle présentation de Gijs Molenaar qui a créé une belle application web pour présenter les données d'imagerie radioastronomiques issues du LOFAR.
    • enfin, Thomas Kluyver et Matthias Bussonnier nous ont notamment parlé du projet Jupyter qui permet d'utiliser le notebook IPython avec des noyaux non Python, dont Julia, R et Haskell.

    Posters

    Logilab a eu l'opportunité de prendre part au projet de recherche PAFI (Plateforme d'Aide à la Facture Instrumentale), en développant une application WEB innovante, basée sur CubicWeb, visant à la fois à faciliter le prototypage virtuel d'instruments (à vent pour le moment) et à permettre des échanges de données entre les acteurs de la recherche et les facteurs d'instrument, voire les musées qui possèdent des instruments anciens ou exceptionnels. La plateforme met ainsi en œuvre la Web Audio API et un modèle de collaboration élaboré.

    L'autre poster présenté par Logilab concerne Simulagora, un service en ligne de simulation numérique collaborative, qui permet de lancer des calculs dans les nuages (donc sans investissement dans du matériel ou d'administration système), qui met l'accent sur la traçabilité et la reproductibilité des calculs, ainsi que sur le travail collaboratif (partage de logiciel, de données et d'études numériques complètes).

    Un grand merci à l'équipe d'organisation de l'événement, qui a encore remporté un joli succès cette année.


  • Tester MPI avec CMake et un framework de test comme Boost

    2014/06/20 by Damien Garaud

    Objectif

    Compiler et exécuter un fichier de test unitaire avec MPI.

    Je suppose que :

    • une implémentation de MPI est installée (nous prendrons OpenMPI)
    • les bibliothèques Boost MPI et Boost Unit Test Framework sont présentes
    • vous connaissez quelques rudiments de CMake

    CMake

    On utilise le bien connu find_package pour Boost et MPI afin de récupérer tout ce qu'il nous faut pour les headers et les futurs links.

    find_package (MPI REQUIRED)
    find_package (Boost COMPONENTS mpi REQUIRED)
    
    # Boost dirs for headers and libs.
    include_directories (SYSTEM ${Boost_INCLUDE_DIR})
    link_directories (${Boost_LIBRARY_DIRS})
    

    Par la suite, on a essentiellement besoin des variables CMake :

    • Boost_MPI_LIBRARY pour le link avec Boost::MPI
    • MPI_CXX_LIBRARIES pour le link avec la bibliothèque OpenMPI
    • MPIEXEC qui nous donne la commande pour lancer un exécutable via MPI

    On prend un fichier example_mpi.cpp (des exemples simples sont faciles à trouver sur la Toile). Pour le compiler, on fait :

    set(CMAKE_CXX_COMPILER mpicxx)
    
    # MPI example.
    add_executable(example_mpi example_mpi.cpp)
    target_link_libraries(example_mpi ${MPI_CXX_LIBRARIES})
    

    voire juste

    target_link_libraries(example_mpi ${Boost_MPI_LIBRARY})
    

    si on décide d'utiliser la bibliothèque Boost MPI.

    Note

    mpicxx est une commande qui enrobe le compilateur (g++ par exemple). On dit à CMake d'utiliser mpicxx au lieu du compilo par défaut.

    Note

    Boost::MPI n'est pas une implémentation de MPI. C'est une bibliothèque plus haut niveau qui s'abstrait de l'implémentation de MPI. Il faut nécessairement en installer une (OpenMPI, LAM/MPI, MPICH2, ...).

    L'exemple peut très simplement ressembler à :

    #include <boost/mpi/environment.hpp>
    #include <boost/mpi/communicator.hpp>
    #include <iostream>
    
    namespace mpi = boost::mpi;
    
    int main()
    {
      mpi::environment env;
      mpi::communicator world;
      std::cout << "I am process " << world.rank() << " of " << world.size()
                << "." << std::endl;
      return 0;
    }
    

    Exécuter

    Une fois la compilation effectuée, faire simplement :

    > mpiexec -np 4 ./example_mpi
    

    pour lancer l'exécutable sur 4 cœurs.

    Problème : mais pourquoi tu testes ?

    On veut pouvoir faire des exécutables qui soient de vrais tests unitaires et non pas un exemple avec juste une fonction main. De plus, comme j'utilise CMake, je veux pouvoir automatiser le lancement de tous mes exécutables via CTest.

    Problème : il faut bien initialiser et bien dire à MPI que j'en ai fini avec toutes mes MPI-series.

    En "vrai" MPI, on a :

    int main(int argc, char* argv[])
    {
      MPI_Init(&argc, &argv);
    
      int rank;
      MPI_Comm_rank(MPI_COMM_WORLD, &rank);
      // Code here..
      // ... and here
      MPI_Finalize();
    
      return 0;
    }
    

    Note

    C'est ce que fait le constructeur/destructeur de boost::mpi::environment.

    En d'autres termes, je veux me faire ma propre fonction main pour l'initialisation de tous mes cas tests Boost (ou avec n'importe quel autre framework de test unitaire C/C++).

    La documentation de Boost Unit Test, que je trouve parfois très peu claire avec un manque cruel d'exemple, m'a fait galérer quelques heures avant de trouver quelque chose de simple qui fonctionne.

    Conseil : aller regarder les exemples des sources en faisant quelques grep est parfois plus efficace que de trouver la bonne info dans la doc en ligne. On peut aussi en lire sur https://github.com/boostorg/test/tree/master/example

    Deux solutions :

    1. la première que j'ai trouvée dans les tests de Boost::MPI lui-même. Ils utilisent le minimal testing facility. Mais seule la macro BOOST_CHECK est utilisable. Et oubliez les BOOST_CHECK_EQUAL ainsi que l'enregistrement automatique de vos tests dans la suite de tests.
    2. la deuxième redéfinit la fonction main et appelle boost::unit_test::unit_test_main sans définir ni la macro BOOST_TEST_MODULE ni BOOST_TEST_MAIN qui impliquent la génération automatique de la fonction main par le framework de test (que l'on compile en statique ou dynamique). Pour plus de détails, lire http://www.boost.org/doc/libs/release/libs/test/doc/html/utf/user-guide/test-runners.html

    J'utiliserai la deuxième solution.

    Note

    Ne pensez même pas faire une fixture Boost pour y mettre votre boost::mpi::environment puisque cette dernière sera construite/détruite pour chaque cas test (équivalent du setUp/tearDown). Et il est fort probable que vous ayez ce genre d'erreur :

    *** The MPI_Errhandler_set() function was called after MPI_FINALIZE was invoked.
    *** This is disallowed by the MPI standard.
    *** Your MPI job will now abort.
    [hostname:11843] Abort after MPI_FINALIZE completed successfully; not able to guarantee that all other processes were killed!
    

    Un exemple qui marche

    On souhaite ici tester que le nombre de procs passés en argument de mpiexec est au moins 2.

    Le BOOST_TEST_DYN_LINK dit juste que je vais me lier dynamiquement à Boost::Test.

    #define BOOST_TEST_DYN_LINK
    #include <boost/test/unit_test.hpp>
    
    #include <boost/mpi/environment.hpp>
    #include <boost/mpi/communicator.hpp>
    
    namespace mpi = boost::mpi;
    
    BOOST_AUTO_TEST_CASE(test_check_world_size)
    {
        mpi::communicator world;
        BOOST_CHECK(world.size() > 1);
    }
    
    
    // (empty) Initialization function. Can't use testing tools here.
    bool init_function()
    {
        return true;
    }
    
    int main(int argc, char* argv[])
    {
        mpi::environment env(argc, argv);
        return ::boost::unit_test::unit_test_main( &init_function, argc, argv );
    }
    

    On lance tout ça avec un joli mpiexec -np 2 ./test_mpi et on est (presque) content.

    Et un peu de CTest pour finir

    Une dernière chose : on aimerait dire à CMake via CTest de lancer cet exécutable, mais avec mpiexec et les arguments qui vont bien.

    Un cmake --help-command add_test nous indique qu'il est possible de lancer n'importe quel exécutable avec un nombre variable d'arguments. On va donc lui passer : /usr/bin/mpiexec -np NB_PROC ./test_mpi.

    Un œil au module FindMPI.cmake nous dit aussi qu'on peut utiliser d'autres variables CMake MPI pour ce genre de chose.

    Reprenons donc notre fichier CMake et ajoutons :

    add_executable(test_mpi test_mpi.cpp)
    target_link_libraries(test_mpi ${Boost_MPI_LIBRARY})
    # Number of procs for MPI.
    set (PROCS 2)
    # Command to launch by CTest. Need the MPI executable and the number of procs.
    add_test (test_mpi ${MPIEXEC} ${MPIEXEC_NUMPROC_FLAG} ${PROCS}
       ${MPIEXEC_PREFLAGS}
       test_mpi
       ${MPIEXEC_POSTFLAGS})
    

    où mon exécutable et mon test porte le même nom : test_mpi. On lance le tout avec la commande ctest dans notre dossier de build et hop, le tour est joué !


  • Compte rendu présentation Salt à Solution Linux

    2014/05/21 by Arthur Lutz

    Logilab était à l'édition 2014 de Solutions Linux qui se déroulait au CNIT à Paris. David Douard participait à la table ronde sur les outils libres pour la supervision lors de la session Administration Système, Devops, au cours de laquelle un certain nombre de projets libres ont été mentionnés : nagios, shinken, graphite, ElasticSearch, logstash, munin, saltstack, kibana, centreon, rsyslog.

    http://www.logilab.org/file/248048/raw/solutionlinux.png

    Suite à des présentations sur OpenLDAP, LXC, btrfs et ElasticSearch David Douard a présenté notre approche agile de l'administration système articulée autour de Salt et en particulier le principe de l'administration système pilotée par les tests (diapos) (Test-Driven Infrastructure).

    https://www.logilab.org/file/248098/raw/Screenshot%20from%202014-05-21%2017%3A55%3A35.png

    Merci aux organisateurs de Solutions Linux pour cette édition 2014.


  • Quelques pointeurs présentés lors d'un atelier sur le web sémantique à Nantes

    2014/05/14 by Arthur Lutz

    À l'appel du DataLab Pays de la Loire, nous avons co-animé (avec Hala Skaf-Molli) un atelier sur le web sémantique à la Cantine Numérique de Nantes.

    Voici quelques diapos avec essentiellement des pointeurs pour donner des exemples de réalisations web sémantique mais aussi pour appuyer les concepts présentés. Vous trouverez les diapos de Hala Skaf sur sa page web (dans les prochains jours).

    Si vous avez raté cette session et êtes intéressé par le sujet, n'hésitez pas à le faire savoir au DataLab.

    http://www.datalab-paysdelaloire.org/auth/public/images/datalab.png

  • Open Science à Toulouse : barcamp sur les Biens Communs

    2014/04/16 by Anthony Truchet

    Le deuxième apéritif et barcamp de la communauté Open Science Toulousaine aura lieu le 24 avril à 19h00 au bar El Deseo, 11 rue des Lois, à deux pas du Capitole et de St Sernin sur le thème des biens communs.

    Plus d'informations sur http://hackyourphd.org/2014/04/aperitif-open-science-toulouse-les-biens-communs/


  • 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 !


  • Naissance de la communauté Open Science Toulousaine

    2014/04/02 by Anthony Truchet

    Ils étaient une vingtaine à se (re)trouver à l’occasion du premier apéritif & barcamp Open Science à Toulouse organisé par Logilab et Hack your PhD. La plupart étaient avant tout curieux de voir qui et quoi se cachaient derrière cette annonce :

    un rendez-vous périodique, informel et sympathique a pour but de favoriser les échanges entre tous les acteurs intéressés par un aspect de l’Open Science : Open Data, les rapports Sciences & Société, Open Source, Open Access, Big Data & Data Science, etc.

    Curieux souvent parce qu’ils s’étaient reconnus dans l’une ou l’autre – et souvent plusieurs – de ces facettes de l’Open Science sans avoir déjà rencontré l’étiquette Open Science pour autant.

    Les échangent se nouent dans la communauté Open Science

    Mais alors l’Open Science : c’est quoi ?

    Heureusement personne n’a asséné de définition définitive. J’ai tenté de montrer, à travers une brève présentation de Hack your PhD et de Logilab comment l’Open Science est avant tout une démarche d’ouverture dans la pratique de la recherche scientifique qui s’étend au delà du cadre du laboratoire.

    L’objectif de la soirée était de permettre à la communauté Open Science locale de se découvrir ; aux acteurs de science ou d’ouverture de faire connaissance. De fait les discussions et prises de contacts informelles allaient bon train autour d’un verre et quelques tapas… et c’est donc à chacun des participants de partager ses échanges sur le thème que fait-on à Toulouse ?

    Le fournisseur d’accès associatif tetaneutral nous met à disposition une liste de diffusion à l’adresse open-science-toulouse@lists.tetaneutral.net. Merci à eux ! J’invite vivement les participants à l’apéro à s’y présenter en quelques mots : faites nous part de votre perception de cet événement et partager vos intérêts et projets.

    On se retrouvera bientôt pour un prochain événement qui tiendra plus de l’atelier. Quelques suggestion qui sont dores et déjà apparues : un atelier sur les outils pratiques pour être ouvert, un séminaire dans un centre de recherche universitaire, un atelier sur les alignements de données publiques et l’évolutivité des schéma de données avec CubicWeb, …

    Vos propositions sont très bienvenues : la communauté Open Science Toulousaine deviendra ce qu’ensemble nous en ferons !

    Ce compte rendu a été initialement publié sur le site de hackyourphd : http://hackyourphd.org/2014/02/naissance-de-la-communaute-toulousaine/


  • Ecriture de liaisons C++ pour Python

    2014/03/13 by Laura Médioni

    Dans le cadre des travaux d'interfaçage de l'application Code_TYMPAN avec du code Python, nous avons réalisé l'étude ci-dessous sur les différents moyens de générer des liaisons Python pour du code C++. Cette étude n'a pas vocation à être exhaustive et s'est concentrée sur les aspects qui nous intéressaient directement pour les travaux susmentionnés.

    Solutions existantes

    Une recherche des solutions existantes a été effectuée, qui a permis d'obtenir la liste suivante pour une écriture manuelle du code d'interfaçage :

    • Cython, un langage de programmation inspiré de Python, basé sur Pyrex
    • Boost.Python, une librairie C++ de la collection Boost permettant d'écrire des liaisons Python
    • PyBindGen, un outil implémenté en Python et permettant de décrire des liaisons C++ directement dans ce langage
    • Swig, un outil permettant de générer des liaisons C++ pour plusieurs langages de programmation
    • Shiboken, un générateur de code d'enrobage pour des bibliothèques C/C++ basé sur du CPython

    Des solutions existent pour automatiser cette écriture. Ce sont des outils qui se basent sur des compilateurs (gcc, clang) pour faire l'analyse grammaticale du code C++ et générer le code d'interfaçage correspondant. Par exemple :

    • XDress, qui permet de générer des fichiers Cython (.pyx, .pxd) à partir de gcc-xml ou de libclang
    • PyBindGen dispose de fonctionnalités permettant de générer des liaisons python à partir de gcc
    • Ce billet explique comment utiliser libclang pour parcourir l'AST d'un code C++ et générer des liaisons Boost.Python

    Aspects pris en compte

    Cet article est intéressant car il aborde de façon très complète les problématiques découlant de l'écriture de liaisons C++ pour des langages de haut niveau. Il a été écrit lors des travaux de développement de Shiboken.

    Dans notre cas, les critères pour le choix d'une solution finale portaient sur différents aspects :

    • Le coût de développement : prise en main de l'outil, quantité de code à écrire pour enrober une classe C++ donnée, coût de l'intégration dans le système de build, degré d'automatisation de la solution, lisibilité du code généré, etc.
    • La gestion de la mémoire : comptage de référence, gestion de la propriété des objets
    • La qualité et l'exhaustivité du support C++ : compatibilité STL, gestion des références et pointeurs, des templates, surcharges d'opérateurs, etc.
    • La pérennité de la solution : technologies mises en œuvre par l'outil, qualité de la documentation, support, taille et degré d'activité de la communauté de développeurs

    Solutions envisagées

    Swig n'a pas été retenu partant de l'a priori que c'était une solution plutôt lourde et davantage orientée C que C++, constat tiré lors de travaux réalisés par Logilab il y a quelques mois de cela. La solution Boost.Python n'a pas été explorée car notre souhait était de nous rapprocher davantage du Python que du C++. Shiboken semble prometteur, bien que peu documenté et mal référencé (les premières recherches tombent sur d'anciennes pages du projet, donnant l'impression que la dernière release date d'il y a plusieurs années, alors qu'en fait, non). Il a été écarté par manque de temps.

    PyBindGen et Cython ont fait l'objet de tests.

    La cible des tests a été l'interfaçage de smart pointers, puisque cela correspond à un de nos besoins sur le projet Code_TYMPAN.

    Les essais ont été réalisés sur des classes simplifiées:

    • MyElement, classe qui représente un élément à encapsuler dans un smart pointer et hérite de IRefCount qui implémente un comptage de référence
    • SmartPtr, classe smart pointer "maison" de l'application
    • Quelques fonctions de test manipulant des smart pointers SmartPtr

    Voici un extrait des en-têtes du code C++:

    #ifndef MY_ELEMENT_H
    #define MY_ELEMENT_H
    #include <iostream>
    using namespace std;
    #include "SmartPtr.h"
    
    class MyElement : public IRefCount
    {
        public:
            MyElement ();
            MyElement (string);
                string Name(){ return _name; }
                virtual ~MyElement ();
    
        protected:
            string _name;
    };
    typedef SmartPtr<MyElement> SPMyElement;
    #endif
    
    #ifndef SMART_PTR_H
    #define SMART_PTR_H
    template <class T> class SmartPtr
    {
        public:
            SmartPtr();
            SmartPtr(T*);
            const T* getRealPointer() const;
    
        protected:
            T* _pObj;
    }
    #endif
    
    SPMyElement BuildElement();
    void UseElement(SPMyElement elt);
    

    Cython

    Cet outil offre maintenant un bon support du C++ (globalement depuis la version 0.17). Son avantage est qu'il permet la manipulation d'objets à la fois C++ et Python dans des fichiers Cython.

    Utilisation
    • Écriture (facultative) d'un fichier .pxd qui contient une recopie des headers à enrober (avec un lien vers les fichiers): déclarations des types, classes, fonctions...
    • Écriture d'un fichier .pyx qui contient des appels de fonctions, constructions d'objets C ou python. Les fonctions et classes de ce module sont utilisables depuis un script Python
    • Compilation du code Cython décrivant les interfaçages C++, génération et compilation du code C++ correspondant et production d'une librairie Python.

    Cython offre un support pour les conteneurs de la STL, les templates, la surcharge de la plupart des opérateurs ("->" non supporté), le passage d'arguments par référence et par pointeur, etc.

    Actuellement en version 0.20.1, la dernière release date du 11 février 2014. Les outils Cython sont relativement bien documentés et sa communauté de développeurs est active.

    Exemple

    Voici le code d'interfaçage Cython correspondant à l'exemple exposé ci-dessus:

    setup.py:

    from distutils.core import setup
    from Cython.Build import cythonize
    
    setup(name='smartptr',
        ext_modules=cythonize('*.pyx',
            ),
    )
    

    smartptr.pxd:

    from libcpp.string cimport string
    
    cdef extern from "src/SmartPtr.h":
        cdef cppclass SmartPtr[T]:
            SmartPtr()
            SmartPtr(T *)
            T *getRealPointer() # Pas de surcharge de ->. L'accès à l'objet ne peut être qu'explicite
    
    cdef extern from "src/MyElement.h":
        cdef cppclass MyElement:
            MyElement()
            MyElement(string)
            string Name()
    
    cdef extern from "src/Test.h":
        SmartPtr[MyElement] BuildSPElement()
        void UseSPElement(SmartPtr[MyElement])
    

    smartptr.pyx:

    # distutils: language = c++
    # distutils: libraries = element
    
    cimport smartptr
    cimport cython
    
    cdef class PySPMyElement:
        cdef SmartPtr[MyElement] thisptr
    
        def __cinit__(self, name=""):
            """ PySPMyElement constructor """
            if name == "":
                self.thisptr = SmartPtr[MyElement](new MyElement())
            else:
                self.thisptr = SmartPtr[MyElement](new MyElement(name))
    
        def get_name(self):
            """ Returns the name of the element """
            return self.thisptr.getRealPointer().Name()
    
    @cython.locals(elt=PySPMyElement)
    def build_sp_elt():
        """ Calls the C++ API to build an element """
        elt = PySPMyElement.__new__(PySPMyElement)
        elt.thisptr = BuildSPElement()
        return elt
    
    @cython.locals(elt=PySPMyElement)
    def use_sp_elt(elt):
        """ Lends elt to the C++ API """
        UseSPElement(elt.thisptr)
    

    XDress

    XDress est un générateur automatique de code d'interfaçage C/C++ écrit en Python, basé sur Cython.

    Utilisation
    • On liste dans un fichier xdressrc.py les classes et fonctions à envelopper (il n'est pas nécessaire de mettre la signature, le nom suffit. On peut choisir d'envelopper seulement certaines classes d'un .h).
    • On exécute xdress qui génère les .pyx et .pxd correspondants

    XDress permet d'envelopper des conteneurs STL via son générateur stlwrap (les conteneurs à enrober doivent être listés dans le xdressrc.py). A titre d'exemple, les vecteurs sont convertis en numpy array du type contenu.

    Ce projet est récent et pas très documenté, mais il semble prometteur.

    PyBindGen

    Utilisation
    • Écriture d'un script Python qui décrit les classes/fonctions C++ à enrober en s'appuyant sur le module PyBindGen (1) → permet de générer un fichier .cpp
    • Compilation du code C++ généré, avec la librairie du programme à envelopper et génération d'une librairie Python.

    Ce processus peut être automatisé:

    • Écriture d'un script Python qui utilise les outils PyBindGen pour lister les modules (headers) à envelopper, les lire et lancer la génération automatique des liaisons c++

    ou:

    • Écriture d'un script Python qui utilise les outils PyBindGen pour lister les modules (headers) à envelopper et générer le script Python décrit en (1) (ce qui permettrait une étape intermédiaire pour personnaliser les liaisons)

    PyBindGen offre un support pour la STL, l'héritage (multiple), la gestion des exceptions C++ côté Python, la surcharge d'opérateurs, le comptage de référence, la gestion de la propriété des objets. Mais il supporte mal les templates.

    Actuellement en version 0.17, la dernière release date du 15 février 2014 (entre autres ajout de la compatibilité Python 3.3).

    Exemple

    PyBindGen, en l'état, n'offre pas la possibilité d'envelopper simplement des templates, ni des smart pointers "maison" par extension.

    Une classe de ce package permet d'envelopper des shared pointers de Boost (boost::shared_ptr). Il serait à priori possible de la modifier légèrement pour enrober les smart pointers de l'application Code_TYMPAN (non testé).

    Voici néanmoins à titre d'exemple le code permettant d'envelopper la classe MyElement et des fonctions manipulant non plus des smart pointers mais des 'MyElement *'

    Test.h :

    MyElement *BuildElement();
    void UseElement(MyElement *elt);
    

    smartptr.py :

    import pybindgen
    import sys
    from pybindgen import retval
    from pybindgen import param
    
    mod = pybindgen.Module('smartptr')
    
    # File includes
    mod.add_include('"src/MyElement.h"')
    mod.add_include('"src/Test.h"')
    
    # Class MyElement
    MyElement = mod.add_class('MyElement')
    MyElement.add_constructor([])
    MyElement.add_method('Name', retval('std::string'), [])
    
    
    # Test functions
    # transfer_ownership=False : here Python program keeps the ownership of the element it passes to the C++ API
    mod.add_function('UseElement', None, [param('MyElement *', 'elt', transfer_ownership=False)])
    # caller_owns_return=True : here Python program will be responsible for destructing the element returned by BuildElement
    mod.add_function('BuildElement', retval('MyElement *',  caller_owns_return=True), [])
    
    if __name__ == '__main__':
        mod.generate(sys.stdout)
    

    Boost.Python

    Les liaisons Python s'écrivent directement en C++.

    C'est un outil très fiable et pérenne, avec de par sa nature un très bon support C++ : gestion de la mémoire, templates, surcharges d'opérateurs, comptage de référence, smart pointers, héritage, etc.

    Inconvénient : la syntaxe (en mode templates C++) n'est pas très intuitive.

    Conclusion

    Les solutions Cython et PyBindGen ont été explorées autour de la problématique d'enrobage de smart pointers. Il en est ressorti que:

    • Il est possible d'enrober facilement des smart pointers Code_TYMPAN en Cython. L'approche qui a été choisie est de manipuler depuis Python les objets C++ directement au travers de smart pointers (les objets Python contenus dans le .pyx encapsulent des objets SmartPtr[T *], agissant donc comme des proxys vers les objets). De cette façon, l'utilisation depuis Python d'un objet C++ incrémente le compteur de référence côté C++ et cela garantit qu'on ne perdra pas la référence à un objet au cours de son utilisation côté Python. Un appel à getRealPointer() pour enrober des fonctions manipulant directement des T * sera toujours possible dans le code Cython au besoin.
    • PyBindGen présente l'intérêt d'offrir des moyens de gérer l'attribution de la propriété des éléments entre C++ et Python (transfer_ownership, caller_owns_return). Malheureusement, il n'offre pas la possibilité d'enrober des smart pointers sans modification de classes PyBindGen, ni d'envelopper des templates.

    Par ailleurs, après utilisation de PyBindGen, il nous a semblé que bien qu'il présente des idées intéressantes, sa documentation, ses tutoriels et son support sont trop succints. Le projet est développé par une seule personne et sa viabilité est difficile à déterminer. Cython en revanche offre un meilleur support et plus de fiabilité.

    Le choix final s'est donc porté sur Cython. Il a été motivé par un souci d'utiliser un outil fiable limitant les coûts de développement (élimination de PyBindGen), aussi proche de Python que possible (élimination de Boost.Python). Cet outil semble fournir un support C++ suffisant par rapport à nos besoins tels que perçus à ce stade du projet.

    De plus si on cherche un moyen de générer automatiquement les liaisons Python, XDress présente l'avantage de permettre l'utilisation de libclang comme alternative à gcc-xml (PyBindGen est basé sur gcc-xml uniquement). Une possibilité serait par ailleurs d'utiliser XDress pour générer uniquement le .pxd et d'écrire le .pyx manuellement.

    Une question qui n'a pas été abordée au cours de cette étude car elle ne correspondait pas à un besoin interne, mais qui est néanmoins intéressante est la suivante: est-il possible de dériver depuis Python des classes de base définies en C++ et enveloppées en Cython, et d'utiliser les objets résultants dans l'application C++ ?


  • Mini compte rendu Meetup Debian à Nantes

    2014/03/13 by Arthur Lutz

    Hier soir, je suis allé au premier meetup Debian à Nantes. C'était bien sympatique, une vingtaine de personnes ont répondu présent à l'appel de Damien Raude-Morvan et Thomas Vincent. Merci à eux d'avoir lancé l'initiative (le pad d'organisation).

    //www.logilab.org/file/228927/raw/debian-france.jpg

    Après un tour de table des participants, et de quelques discussions sur debian en général (et une explication par Damien de l'état de Java dans Debian), Damien a présenté l'association Debian France ainsi que le concours du nouveau contributeur Debian. La liste d'idées est longue et sympatique n'hésitez pas à aller jeter un oeil et faire une contribution.

    Ensuite Thomas nous a présenté l'équipe de traduction francaise de debian et ses principles de fonctionnement (qualité avant quantité, listes de discussion, IRC, processus de traduction, etc.).

    //www.logilab.org/file/228931/raw/saltstack_logo.jpg

    Finalement, j'ai rapidement présenté Salt et sa place dans Debian. Pour l'archive publique : les diapos de la présentation.

    À la prochaine !

    Pour faire un commentaire, il faut s'authentifier ou s'enregistrer.


  • Retour sur MiniDebConf Paris 2014

    2014/03/05 by Arthur Lutz
    http://www.logilab.org/file/226609/raw/200px-Mini-debconf-paris.png

    Nous sommes heureux d'avoir participé à la MiniDebConf Paris.

    Nous avons sponsorisé l'évenement mais aussi effectué deux présentations :

    • Julien Cristau a présenté l'équipe dont il fait partie pour la prochaine release de debian : Jessie. Il a notamment donné des conseils à la communauté sur la préparation de jessie. Voici ces diapos : Release team: Jessie.
    • David Douard a présenté Salt to administrate Debian systems, introduisant Salt avec un focus particulier sur ce que Salt peut apporter à de l'administration d'un parc de machines sous Debian.

    Avec une cinquantaine de participants sur les deux jours, c'est toujours agréable de rencontrer la communauté francaise autour de Debian. Merci donc à l'association Debian France d'avoir organisé cette conférence.


  • InfoLab Rennes - 17 décembre

    2013/12/18 by Arthur Lutz

    InfoLab Rennes - 17 décembre

    Le mardi 17 décembre, nous avons participé à la 4ème rencontre du groupe national infolab à Rennes. Voici quelques notes et reflexions prises à cette occasion. La journée a été dense, donc vous ne trouverez que des bribes des sujets dans ce compte rendu.

    http://www.fing.org/local/cache-vignettes/L680xH165/_info_lab_V3_logo_petit-d6f63.jpg

    Présentation générale le matin

    Une présentation générale de la mission "infolab" menée par le Fing a permis d'initier la réflexion et la discussion sur ce qu'est un infolab. Sarah Labelle (Université Paris XIII), Amandine Brugières (Poitiers), Claire Gallon (Nantes, Libertic), Simon Chignard (Rennes), Charles Nepote (Marseille), et Thierry Marcou (Paris) se sont succédé pour expliquer les réflexions et outils en cours d'élaboration. Nous avons noté :

    • une liste de 150 outils répertoriés pour aider à manipuler les données,
    • un prototype de méthodologie,
    • des documents récapitulatifs sur les différents métiers autour de la donnée.

    L'assemblée se pose la question de comment rendre accessible les technologies, les données, les outils. Il nous semble qe cette démarche n'est possible qu'en ayant des mécanismes transparents, reproductibles et collaboratifs. Nous y voyons donc les principes de "logiciel libre", des "standards" et des "outils collaboratifs". Comment rendre le traitement de la donnée reproductible et transparent ?

    À Logilab, nous avons adoptés les outils suivants pour traiter la données :

    • CubicWeb (en python) avec un certain nombre de cubes (modules type plugins)
    • les standards du web sémantique pour faire de la publication et de l'échange de données (publication de dumps, negociation de contenu et sparql endpoints),
    • les outils de versionning et de collaboration (en logiciel libre) : mercurial qui permettent une co-construction décentralisée sur du code source, mais aussi sur certaines données (voir par exemple les jeux de données publié sur github).

    Au sujet de l'annuaire des outils : comporte-t-il une évaluation de l'accessibilité ? D'un outil WYSIWYG à un outil de programmation... quelle grille de notation ? Faut-il faire son propre graphisme ou est-ce "configurable" sans compétence... Grille d'évaluation aussi sur l'autonomie de l'outil ? Par exemple utiliser Google Drive pose des questions des droits sur les données (exemple récent sur la propriété des données lorsqu'elles sont affichées sur une carte google à travers l'API). Dans le domaine du logiciel libre, avec lequel nous pouvons établir un bon nombre de parallèles, il existe des méthodes formelles d'évaluation.

    D'autres questions ont été abordées :

    • stockage et pérennité des démarches et des données : dans l'industrie logicielle une formalisation pertinente en rapport avec cette question est le semantic versionning qui permet d'établir une traçabilité. Sur l'archivage, de nombreuses solutions sont envisageables mais pas forcément formalisées (stockage P2P, hébergement mutualisé, etc).
    • le contrôle d'accès : qui accède comment, comment partage-t-on de manière sécurisée ? Ceci nous fait penser aux études menées par le MIT sur leur projet OpenPDS.
    • comment rendre le crowdsourcing efficace ? Des outils comme CrowdCarfting (PyBossa en Python) permettraient de "simplement" définir une application de crowdsourcing (eg. cartographie, annotation d'image, classement d'image, OCR collaboratif, etc.) mais comment faire le lien avec les données "officielles" ?

    Atelier l'après-midi

    Suite à une visite du labfab de Rennes, nous avons participé aux ateliers, étant deux personnes de chez Logilab, nous avons pu participer à trois ateliers :

    • travail sur la charte des infolabs,
    • datavisualisation et réflexions autour des données,
    • comment mener une campagne de crowdsourcing et sur quels types de données.

    Dans l'atelier sur le crowdsourcing, nous avons parlé rapidement de CKAN et http://datahub.io/ qui sont des moteurs de recherche sur les jeux de données ouverts.

    La suite

    Nous avons participé à DataPride (à Nantes) et comptons participer dans le futur à DataLab (à Nantes) et DataShacker (à Paris), s'agit-il d'initiatives "compatibles" avec les principes des infolabs ? Sont-ce des infolabs ? La suite de l'initiative nous le dira sûrement.

    Les prochaines rencontres Infolab auront probablement lieu à Bordeaux en janvier et à Paris lors de Futur en Seine (du 12 au 15 juin : au CNAM, à la Gaité Lyrique, au Square Emile Chautemps).


  • Lecture de données tabulées avec Numpy -- Retour d'expérience sur dtype

    2013/12/17 by Damien Garaud

    Ce billet est un petit retour d'expérience sur l'utilisation de Numpy pour lire et extraire des données tabulées depuis des fichiers texte.

    Chaque section, hormis les objectifs ou la conclusion, correspond soit à une difficulté rencontrée, une remarque technique, des explications et références vers la documentation officielle sur un point précis qui m'a fait patauger quelques temps. Il y a de forte chance, pour certains d'entre vous, que les points décrits ici vous paraissent évidents, que vous vous disiez "mais qui ne sait pas ça ?!". J'étais moi-même le premier étonné, depuis que je connais Numpy, de ne pas savoir ce genre de choses. Je l'étais moins quand autour de moi, mes camarades ne semblaient pas non plus connaître les petites histoires numpysiennes que je vais vous conter.

    http://www.logilab.org/file/203839/raw/numpylogo.png

    Objectifs

    Le Pourquoi et le Où on va au fait ?

    J'avais sous la main des fichiers aux données tabulées, type CSV, où les types de données par colonne étaient clairement identifiés. Je ne souhaitais pas passer du temps avec le module csv de la bibliothèque standard à convertir chaque élément en type de base, str, flottants ou dates. Numpy étant déjà une dépendance du projet, et connaissant la fonction np.genfromtxt, j'ai évidemment souhaité l'utiliser.

    Il était nécessaire de ne lire que certaines colonnes. Je souhaitais associer un nom à chaque colonne. L'objectif était ensuite d'itérer sur ces données ligne par ligne et les traiter dans des générateurs Python. Je n'utilise pas ici Numpy pour faire des opérations mathématiques sur ces tableaux à deux dimensions avec des types hétérogènes. Et je ne pense d'ailleurs pas qu'il soit pertinent d'utiliser ce type de tableau pour faire ces opérations.

    dtypes différents, str et extraction de chaînes vides

    On utilise ici l'argument dtype des fonctions telles que np.genfromtxt pour lire des fichiers tabulés dont les colonnes sont de types différents.

    Attention au dtype à passer à np.genfromtxt ou np.recfromtxt quand on parse des données tabulée (file ou stream). Pour parser une colonne de chaînes de caratères, lui passer [('colname', str)] renvoie des chaînes vides si les autres dtypes sont de types différents.

    Il faut préciser la taille :

    dtype=[('colname', str, 10)]
    # or
    dtype=[('colname', 'S10')]
    

    Ou alors prendre un "vrai" objet str Python :

    dtype=[('colname', object)]
    

    aussi équivalent à:

    dtype=[('colname', 'object')]
    

    Et oui, je suis littéralement tombé sur l'évidence, les "types Numpy", c'est du type C. Et les chaînes, c'est du char * et il y a donc besoin de la taille. La solitude s'est fait moindre quand j'ai su que je n'étais pas le seul à être tombé sur des données tronquées voire vides.

    dtype et tableau à zéro dimension

    Attention au tableau Numpy 0D quand le contenu tabulé à parser n'a qu'une seule ligne (cas d'un np.[rec]array avec plusieurs dtypes). Impossible d'itérer sur les éléments puisque dimension nulle.

    Supposons que vous ayez un fichier tabulé d'une seule ligne :

    Name,Play,Age
    Coltrane,Saxo,28
    

    J'utilise np.genfromtxt en précisant le type des colonnes que je souhaite récupérer (je ne prends pas en compte ici la première ligne).

    data = np.genfromtxt(filename, delimiter=',',
                         dtype=[('name', 'S12'), ('play', object), ('age', int)],
                         skip_header=1)
    

    Voici la représentation de mon array :

    array(('Coltrane', 'Saxo', 28),
        dtype=[('name', 'S12'), ('play', 'O'), ('age', '<i8')])
    

    Si dans votre code, vous avez eu la bonne idée de parcourir vos données avec :

    for name, instrument, age in data:
        # ...
    

    vous pourrez obenir un malheureux TypeError: 'numpy.int64' object is not iterable par exemple. Vous n'avez pas eu de chance, votre tableau Numpy est à zéro dimension et une shape nulle (i.e. un tuple vide). Effectivement, itérer sur un objet de dimension nulle n'est pas chose aisée. Ce que je veux, c'est un tableau à une dimension avec un seul élément (ici un tuple avec mes trois champs) sur lequel il est possible d'itérer.

    Pour cela, faire:

    >>> print data
    array(('Coltrane', 'Saxo', 28),
          dtype=[('name', 'S12'), ('play', 'O'), ('age', '<i8')])array(('babar', 42.), dytpe=[('f0', 'S5'), ('f1', '<f8')])
    >>> print data.shape, data.ndim
    (), 0
    >>> data = data[np.newaxis]
    >>> print data.shape, data.ndim
    (1,), 1
    

    dtype et str : chararray ou ndarray de strings ?

    Pour les chararray, lire help(np.chararray) ou http://docs.scipy.org/doc/numpy/reference/generated/numpy.chararray.html. En particulier:

    The chararray class exists for backwards compatibility with Numarray, it is not recommended for new development. Starting from numpy 1.4, if one needs arrays of strings, it is recommended to use arrays of dtype object_, string_ or unicode_, and use the free functions in the numpy.char module for fast vectorized string operations.

    On fera donc la distinction entre:

    # ndarray of str
    na = np.array(['babar', 'celeste'], dtype=np.str_)
    # chararray
    ca = np.chararray(2)
    ca[0], ca[1] = 'babar', 'celeste'
    

    Le type de tableau est ici différent : np.ndarray pour le premier et np.chararray pour le second. Malheureusement pour np.recfromtxt et en particulier pour np.recarray, si on transpose le label de la colonne en tant qu'attribut, np.recarray il est transformé en chararray avec le bon type Numpy --- |S7 dans notre cas --- au lieu de conserver un np.ndarray de type |S7.

    Exemple :

    from StringIO import StringIO
    rawtxt = 'babar,36\nceleste,12'
    a = np.recfromtxt(StringIO(rawtxt), delimiter=',', dtype=[('name', 'S7'), ('age', int)])
    print(type(a.name))
    

    Le print rend bien un objet de type chararray. Alors que :

    a = np.genfromtxt(StringIO(rawtxt), delimiter=',', dtype=[('name', 'S7'), ('age', int)])
    print(type(a['name']))
    

    affiche ndarray. J'aimerais que tout puisse être du même type, peu importe la fonction utilisée. Au vue de la documentation et de l'aspect déprécié du type charray, on souhaiterait avoir que du ndarray de type np.str. J'ai par ailleurs ouvert le ticket Github 3993 qui n'a malheureusement que peu de succès :-(

    Tableau de chaînes : quel dtype ?

    Si certains se demandent quoi mettre pour représenter le type "une chaîne de caractères" dans un tableau numpy, ils ont le choix :

    np.array(['coltrane', 'hancock'], dtype=np.str)
    np.array(['coltrane', 'hancock'], dtype=np.str_)
    np.array(['coltrane', 'hancock'], dtype=np.string_)
    np.array(['coltrane', 'hancock'], dtype='S')
    np.array(['coltrane', 'hancock'], dtype='S10')
    np.array(['coltrane', 'hancock'], dtype='|S10')
    

    Les questions peuvent être multiples : est-ce la même chose ? pourquoi tant de choses différentes ? Pourquoi tant de haine quand on lit la doc Numpy et que l'info ne saute pas aux yeux ? À savoir que le tableau construit sera identique dans chacun des cas. Il existe peut-être même d'autres moyens de construire un tableau de type identique en lui passant encore un n-ième argument dtype différent.

    • np.str représente le type str de Python. Il est converti automatiquement en type chaines de caractère Numpy dont la longueur correspond à la longueur maximale rencontrée.
    • np.str_ et np.string_ sont équivalents et représentent le type "chaîne de caractères" pour Numpy (longueur = longueur max.).
    • Les trois autres utilisent la représentation sous forme de chaîne de caractères du type np.string_.
      • S ne précise pas la taille de la chaîne (Numpy prend donc la chaîne la plus longue)
      • S10 précise la taille de la chaîne (données tronquées si la taille est plus petite que la chaîne la plus longue)
      • |S10 est strictement identique au précédent. Il faut savoir qu'il existe cette notation <f8 ou >f8 pour représenter un flottant. Les chevrons signifient little endian ou big endian respectivement. Le | sert à dire "pas pertinent". Source: la section typestr sur la page http://docs.scipy.org/doc/numpy/reference/arrays.interface.html

    À noter que j'ai particulièrement apprécié l'utilisation d'un symbole pour spécifier une information non pertinente --- depuis le temps que je me demandais ce que voulait bien pouvoir dire ce pipe devant le 'S'.

    Conclusion (et pourquoi pas pandas ?)

    http://www.logilab.org/file/203841/raw/pandas_logo.png

    Pandas, bibliothèque Python d'analyse de données basée sur Numpy, propose, via sa fonction read_csv, le même genre de fonctionnalités. Il a l'avantage de convertir les types par colonne sans lui donner d'information de type, qu'on lise toutes les colonnes ou seulement quelques unes. Pour les colonnes de type "chaîne de caractères", il prend un dtype=object et n'essaie pas de deviner la longueur maximale pour le type np.str_. Vous ne rencontrerez donc pas "le coup des chaînes vides/tronquées" comme avec dtype='S'.

    Je ne m'étalerai pas sur tout le bien que je pense de cette bibliothèque. Je vous invite par ailleurs à lire/ parcourir un billet de novembre qui expose un certain nombre de fonctionnalités croustillantes et accompagné d'un IPython Notebook.

    Et pourquoi pas Pandas ? Il ne me semble pas pertinent de dépendre d'une nouvelle bibliothèque, aussi bien soit-elle, pour une fonction, aussi utile soit-elle. Pandas est un projet intéressant, mais jeune, qui ne se distribue pas aussi bien que Numpy pour l'instant. De plus, le projet sur lequel je travaillais utilisait déjà Numpy. Je n'avais besoin de rien d'autre pour réaliser mon travail, et dépendre de Pandas ne me semblait pas très pertinent. Je me suis donc contenté des fonctions np.{gen,rec}fromtxt qui font très bien le boulot, avec un dtype comme il faut, tout en retenant les boulettes que j'ai faites.


  • PyConFr

    2013/10/28 by Alain Leufroy
    http://www.pycon.fr/2013_static/pyconfr/images/banner.png

    Logilab était au rendez-vous annuel des pythonistes de tous genres : la conférence PYCONFR organisée par l'AFPy, qui avait lieu cette année à l'université de Strasbourg.

    Si vous n'y étiez pas, voici un petit aperçu de ce que vous avez raté, sachant que le programme était chargé.

    Où en est le packaging ?

    Nos amis de Unlish ont fait une présentation de l'état actuel de la distribution de paquets python.

    Après une présentation générale de PyPI, ils ont décrit les derniers changements qui ont permis d'améliorer la disponibilité des paquets python.

    L'information la plus importante concernait Wheel qui est le format désormais recommandé pour fournir des binaires précompilés. Fini les .egg de setuptools ! Ceci devrait faire sourir plus d'un mainteneur de paquet ou administrateur système.

    Wheel est un format de fichier de distribution. Ce format clair et succinct est décrit par la PEP427. Il vise à simplifier la fabrication des paquets pour les distributions de vos OS favoris.

    Les versions récentes de l'installeur pip peuvent gérer les paquets Wheel qui sont compatibles avec le système d'installation décrit dans la PEP376. Il faut toutefois, pour l'instant, dire explicitement à pip de prendre en compte ces fichiers dès qu'ils sont disponibles, grâce à l'option --use-wheel.

    Vous disposez ainsi des avantages de pip (gestion claire et simple des dépendances, freeze, désinstallation, etc.) et ceux d'une distribution de paquets précompilés (installation rapide et simple, environnement de développement non requis, etc.).

    Les paquets Wheel prennent en compte les implementations de python et leurs ABIs. Vous pouvez donc fournir des paquets Wheel (et les signer) facilement pour des versions spécifiques de Jython, Pypy, IronPython, etc.

    $ python setup.py bdist_wheel
    $ pypy setup.py bdist_wheel
    

    Cela ne vous dispense pas de distribuer les sources de votre paquet ;)

    $ python setup.py sdist
    

    Python dans Mercurial

    http://www.selenic.com/hg-logo/logo-droplets-50.png

    Pierre-Yves David et Alexis Métaireau ont fait un petit rappel des trucs vraiment géniaux dans Mercurial comme les revsets et les templates.

    Le coeur de leur présentation concernait l'utilisation de Python pour écrire Mercurial.

    D'après son auteur, Mercurial existe aujourd'hui grâce à Python. En effet Python a permis à Matt Mackall d'écrire une preuve de son concept en à peine deux semaines -- il n'avait pas plus de temps à y dédier donc l'implementation en C n'était pas envisageable.

    Rappelons qu'avant de changer le langage d'implementation il est toujours intéressant de se poser des questions sur les algorithmes utilisés. Nous avons vu quelques exemples d'optimisation en Python qui ont permis de d'accélérer Mercurial, et quelques astuces pour contourner les lenteurs que l'on rencontre avec l'interpréteur CPython (lazy import, low-level access, etc.).

    Les autres avantages notables de l'utilisation de Python viennent de sa flexibilité. Les extensions pour Mercurial peuvent grâce à cela changer le comportement interne de Mercurial. Par exemple largefiles et watchman améliorent grandement la gestion des gros fichiers et la mise à jour des informations du dépôt.

    Hy, lisp on Python

    http://docs.hylang.org/en/latest/_images/hy_logo-smaller.png

    Julien Danjou a présenté une implémentation de Lisp basé sur la VM de Python. En effet Python peut être vu comme un sous-ensemble de Lisp.

    Hy interprète un script écrit dans un dialecte de Lisp et le convertit en arbre syntaxique Python classique, qui est ensuite exécuté par l'interpréteur Python.

    [Python] .py -(parse)---> AST -(compile)-> .pyc -(run)-> python vm
                          /
    [Lisp]   .hy -(parse)/
    

    tip

    hy2py permet de montrer l'équivalent Python d'un script Lisp.

    Il y a donc une grande interopérabilité entre ce qui est implémenté en Hy et ce qui l'est en Python. Aucun souci pour importer les autres modules Python, quels qu'ils soient.

    Hy supporte presque toutes les versions de Python et beaucoup d'interpréteurs, notamment pypy.

    De nombreuses fonctions de common Lisp sont disponibles, et Hy se rapproche de Clojure pour la définition des classes.

    Pour ceux qui sont intéressés par Hy, notez qu'il manque encore quelques petites choses :

    • les cons cells sont en cours de discussion
    • il faudra faire sans les macroexpand pour vous aider dans vos macros
    • les fonctions de Common Lisp ne sont pas toutes présentes
    • le dialect de Lisp nécessite, pour l'instant, de mixer les [...]` et les (...)`, mais ceci devrait changer.
    • Hy n'est pas présent à l'exécution, il y a donc forcément des limitations.

    Python pour la Robotique

    Il y avait une présentation bien sympathique d'une équipe qui participe régulièrement aux championnats de france de robotique.

    Ils utilisent une carte basée sur un SoC ARM sur laquelle ils disposent d'un Gnu/Linux et d'un interpréteur Python (2.7).

    Ils ont codé en C/C++ quelques routines de bas niveau pour un maximum de réactivité. Mise à part cela, tout le reste est en Python, notamment leurs algorithmes pour gérer la stratégie de leurs robots.

    Python leur facilite énormément la vie grâce au prototypage rapide, à la rapidité pour corriger leur code (surtout avec le manque de sommeil durant la compétition), à la souplesse pour simuler en amont, analyser des logs, etc.

    Un Python dans la maison

    http://hackspark.fr/skin/frontend/base/default/images/logo3d_hackspark_small.png

    Il y avait aussi la présentation d'un projet (Hack'Spark!) jeune mais déjà fonctionnel de domotique. La petite démonstration en direct du système était du plus bel effet ;)

    Et, pour moins de 100 euros vous pourrez allumer la lumière chez vous depuis une interface web ! Perso, je m'y mets ce mois ;)

    Framework Graphique Kivy

    http://kivy.org/logos/kivy-logo-black-64.png

    Kivy est entièrement écrit en Python/Cython et utilise OpenGL. Il a donc un très bon support sur les machines récentes (Linux, BSD, MacOs, Android, iOS, Rpi, etc.). Et il n'a rien a envier aux autres frameworks.

    Kivy semble particulièrment pratique pour mener à bien des projets sur les plateformes mobiles comme les téléphones portables et les tablettes (Android et iOS).

    De plus, parmi les outils fournis avec Kivy vous pourrez trouver quelques trucs pour simplifier votre développement :

    • PyJNIus utilise l'interface JNI de la VM Java (via Cython). Il sert de proxy sur les classes Java et vous donne donc accès à l'ensemble de l'API Android.
    • PyObjus est le pendant de PyJNIus pour ObjectiveC sous iOS.
    • Plyer essaie de rassembler en une API commune de plus haut niveau PyJNIus et PyObjus, ce qui permet de coder une seule fois pour les deux plateformes.
    • Buildozer aide à la compilation de projet pour Android de manière plus simple qu'avec Python for Android.

    Nous avons eu droit à une présentation des concepts et comment les mettre en œuvre en direct. Je sens que ça va me simplifier la vie !


  • Rencontre autour de SaltStack lors de l'OpenWorldForum

    2013/09/25 by Arthur Lutz

    Suite à l'organisation du sprint français autour de SaltStack, nous continuons d'essayer de fédérer la communauté française utilisatrice (ou tout simplement curieuse) de solutions de gestion centralisées autour de la technologie Salt (qui est écrit en Python et que nous pouvons donc facilement adapter à nos besoins en contribuant au projet).

    http://openworldforum.org/static/pictures/Calque1.png http://saltstack.com/images/SaltStack-Logo.png

    Au sein de l'OpenWorldForum nous animons un SaltStack meetup / BOF le jeudi 3 octobre de 18h30 à 20h30 avec Thomas Hatch fondateur de SaltStack. La totalité de l’événement (dont le meetup) est gratuit, il suffit de s'inscrire.

    Logilab tiendra un stand le jeudi et le vendredi lors du forum, n'hésitez pas à venir discuter avec nous. Le TDI (Test-Driven Infrastructure), qui consiste à appliquer le TDD (Test-driven development) (développement piloté par les tests) à l'administration système sera un des thèmes de notre présence.


  • Compte rendu PGDay France 2013 (Nantes) - partie 2/2

    2013/07/01 by Arthur Lutz

    Ora2Pg: Migration à Grande Vitesse par Gilles Darold

    L'outil ora2pg permet de jouer une migration d'Oracle à Postgresql. Malgré notre absence de besoin de ce type de migration, cette présentation fut l'occasion de parler d'optimisation diverses qui peuvent être appliqué à des imports massifs tel que nous pouvons en pratiquer à Logilab.

    Par exemple :

    • utilisation prioritaire de COPY plutôt que INSERT,
    • supprimer les indexes/contraintes/triggers/sequences (les créer en fin d'import),
    • maintenir un _work_mem_ élevé (pour la création des index et contraintes),
    • augmenter les checkpoin_segments (>64/1Gb).

    Quelques réglages systèmes peuvent être mis en place le temps du chargement (on les rebranche une fois que le serveur passe en "production") :

    • fsync=off
    • full_page_writes=off
    • synchronous_commit=off
    • WAL (Write Ahead Log) sur des disques SSD
    • kernel : vm.dirty_background_ratio = 1
    • kernel : vm.dirty_ratio = 2

    Coté Postresql, les paramètres suivants sont probablement à modifier (les chiffres sont à titre d'exemple, la configuration matérielle est bien particulière, par exemple 64G de RAM, voir les diapos pour le détail):

    • shared_buffers = 10G
    • maintenacen_work_mem = 2G
    • checkpoint_segments = 61
    • checkpoint_completion_target = 0.9
    • wal_level = minimal
    • archive_mode = off
    • wal_buffer = 32 Mo
    • désactiver les logs
    http://ora2pg.darold.net/ora2pg-logo.png

    Pour aller plus loin voir le support de présentation (5).

    Vers le Peta Byte avec PostgreSQL par Dimitri Fontaine

    Dimitri Fontaine a admirablement bien traité cette question complexe qu'est la montée à l'échelle en terme de volume de données. Son approche fut très didactique, avec, à chaque concept, un rappel de ce dont il s'agisait. Par exemple, parlant du MVCC, il explique qu'il s'agit de plusieurs définitions en parallèle d'une même ligne. Ensuite on décide avec VACUUM quelle version doit être visible par tout le monde. Par défaut AUTOVACCUM se déclenche quand 20% des données ont changé.

    Face aux difficultés et aux inconvénients de stocker la totalité d'une PetaByte sur un seul serveur, Dimitri Fontaine a évoqué les solutions possible en terme d'architecture distribuée pour permettre de stocker ce PetaByte sur plusieurs serveurs répartis. La "Bi-Directional Replication" (qui sera dispo dans le futur) permetterait d'avoir plusieurs bases SQL qui séparément stockent une partie des données (cf EVENT TRIGGERS). Un approche complémentaire serait d'utiliser plproxy qui par des procédures stockées permet de répartir les requêtes sur plusieurs serveurs.

    http://www.logilab.org/file/150419/raw/Screenshot%20from%202013-07-01%2010%3A25%3A46.png

    Finalement, un point qui nous a paru pertinent : il a parlé de haute disponibilité et des flous techniques qui entourent le sujet. Il faut bien faire la différence entre la disponibilité des données et du service. Par exemple, en WARM STANDBY les données sont disponibles mais il faut redémarrer Postgresql pour fournir le service alors que en HOT STANDBY les données sont disponibles et le serveur peut fournir les services.

    Pour aller plus loin voir le support de présentation (6).

    Comprendre EXPLAIN par Guillaume Lelarge

    Utiliser EXPLAIN permet de débugger l’exécution d'une requête SQL ou de l'optimiser. On touche assez rapidement au fonctionnement interne de Postgresql qui est relativement bien documentés. Guillaume Lelarge a donc, à l'aide de nombreux exemples, présenté des mécanismes plutôt bas niveau de Postgresql.

    Notons entre autres les différents types de scans dont les noms sont relativement explicites :

    Dans la même veine, les types de tris :

    • external sort (sur disque),
    • quicksort (en mémoire).

    Mais aussi, prenez le temps de lire les exemples sur son support de présentation (7)

    Conclusion

    https://www.pgday.fr/_media/pgfr2.png

    PGDay.fr est une conférence que nous pouvons vivement vous recommander, proposant un savant mélange des différentes questions auxquelles nous sommes confrontées lorsque nous travaillons avec des bases de données. Aussi bien en tant qu'administrateur système, développeur, ou utilisateur de SQL. Il va sans dire que le niveau technique était très pointu. Les présentations restaient pourtant accessibles. Les orateurs et organisateurs étaient disponibles pour des interactions, permettant de prolonger la réflexion et les discussions au delà des présentations.

    Nous envisageons d'ores et déjà d'aller à l'édition 2014! À l'année prochaine...

    http://www.logilab.org/file/150100/raw/2e1ax_default_entry_postgresql.jpg

  • Compte rendu PGDay France 2013 (Nantes) - partie 1/2

    2013/07/01 by Arthur Lutz

    Quelques personnes de Logilab ont assisté aux PGDay 2013 à Nantes. Voici quelques points qui nous ont marqués.

    http://www.cubicweb.org/file/2932005/raw/hdr_left.png

    Gestion de la capacité des ressources mémoire d'un serveur PostgreSQL par Cédric Villemain

    Cédric Villemain nous a exposé plusieurs pistes d'investigation de la gestion mémoire de Postgresql.

    On peut employer des outils Linux tels que vmstat, pmap, meminfo, numactl, mais aussi des outils spécifiques à Postgresql, tels que pg_stat (hit ratio), pg_buffercache (audit de la mémoire cache), pgfincore (audit du cache de l'OS).

    Il faut mettre des sondes sur les tables et indexes critiques de manière à avoir une idée du fonctionnement "normal" pour ensuite détecter le fonctionnement "anormal". À Logilab, nous utilisons beaucoup munin, pour lequel plusieurs greffons Postgresql sont disponibles : munin pg plugins et pymunin.

    Pour aller plus loin voir le support de présentation (1).

    Les nouveautés de PostgreSQL 9.3 par Damien Clochard

    Damien Clochard a fait une très synthétique présentation des fonctionnalités de la nouvelle version de PostgreSQL 9.3. Le cycle de release de Postgresql dure 1 an, donc la periode de beta est courte, il faut que la communauté soit impliquée pour tester rapidement. Damien en profite pour chanter les louanges de PostgreSQL, qui est, selon lui, le SGBD le plus dynamique au monde: 1 version majeure par an, 4-5 versions mineures par an, et un support de 5 ans des versions majeures.

    Actuellement, cela signifie que 5 versions majeures sont maintenues (notamment en terme de sécurité) en parallèle : 8.4, 9.0, 9.1, 9.2, 9.3beta1. Notons donc que la version 9.3 qui sort bientôt sera donc supportée jusqu'à 2018.

    http://www.logilab.org/file/150442/raw/elephant.png

    Pour les nouveautés, difficiles à résumer, notons néanmoins :

    • des gains de performance,
    • des verrous possibles sur les clés étrangères,
    • une gestion mémoire plus fine,
    • la possibilité de faire des pg_dump en parallèle (--jobs),
    • scénarios supplémentaires de réplication,
    • possibilité de "bascule rapide" en architecture répliquée,
    • facilitation de mise en place d'un serveur clone (génération automatique du fichier recovery.conf),
    • vue matérialisées,
    • opérateurs supplémentaires pour JSON (citation "MongoDB avec la tranquilité (ACID)"),
    • les requètes LATERAL
    • extensibilité avec des processus supplémentaires permettant des opérations de maintenance, de supervision ou d'optimisation,
    • des backends supplémentaires pour les "Foreign Data Wrappers" (introduits en 9.1),
    • possibilité de séparer le fichier de configuration en plusieurs sous-fichiers (utile pour une pilotage par SaltStack par exemple).

    Damien en a profité pour parler un peu des points forts prévus pour la version 9.4 :

    • simplification de la montée en charge,
    • réplication logique (répliquer une seule table par exemple),
    • parallélisation des requêtes (multi-coeurs),
    • stockages internes

    En bref, concis et alléchant. Vivement qu'on ait cette version en production.

    En attendant on a profité pour l'installer à partir des entrepôts Debian gérés par la communauté Postgresql.

    Pour aller plus loin voir le support de présentation (2).

    "Ma base de données tiendrait-elle la charge ?" par Philippe Beaudouin

    Philippe Beaudoin a utilisé pour cette analyse une combinaison de pgbench (injection), et la table pg_stat_statements qui collecte les statistiques sur l'utilisation mémoire des requêtes : produit une table avec les query, nombre d'appels, temps passé, nombre de lignes, etc.

    L'idée générale est d'établir un profil de charge transactionnel sur la production pour pouvoir comparer avec la pré-production ou la future plateforme.

    Pour éviter de devoir copier les données de production (lent, problème de confidentialité, etc), il est conseillé d'utiliser "generate_series" pour remplir la base de données de données de test.

    pgbench utilise des scenario TPC-B (Transaction Processing Performance Council Benchmarks) Pour chaque scénario (4 scénarios dans son exemple) on a une cible TPS (transaction par secondes). Il recommande de faire attention à ne pas modifier considérablement la taille de la base avec les scénarios (ex. trop de DELETE, ou trop d'INSERTs).

    Un astuce pour charger le cache linux

    find <files> -exec dd if='{}' of=/dev/null\;
    

    Si on ne sait pas quels fichiers charger, on peut utiliser pg_relation_filepath(oid) FROM pg_class where relname like 'tbl%' pour trouver en SQL quels fichiers contiennent les données.

    Nous avons demandé si un outil de type GOR (flux UDP de la production vers la pre-production ou le serveur de développement pour les requêtes HTTP) existait pour Postgresql.

    http://www.logilab.org/file/150448/raw/gor.png

    Réponse : Tsung contient un mode proxy qui permet d'enregistrer la production, ensuite de la rejouer en pre-prod, mais pas en mode live. À priori il serait possible de combiner plusieurs outils existant pour faire cela (pgShark ?). La problématique n'est pas simple notamment lorsque les bases de données divergent (index, series, etc).

    Pour aller plus loin voir le support de présentation (3).

    PostGIS 2.x et au delà par Hugo Mercier

    Nous avons trouvé la présentation réussie. Elle introduisait les concepts et les nouveautés de PostGIS 2.x. Ayant intégré des fonctionnalités de PostGIS à CubicWeb et travaillant un peu sur la visualisation en WebGL de données stockées dans CubicWeb+Postgresql, nous avons pu réfléchir à des possibilités de délégation de traitement à la base de donnée.

    http://www.logilab.org/file/150441/raw/Screenshot%20from%202013-07-01%2010%3A30%3A00.png

    Nous nous sommes aussi interrogés sur le passage à l'échelle d'applications web qui font de l'affichage de données géographiques, pour éviter d'envoyer au navigateurs un volume de données trop important (geoJSON ou autre). Il y aurait des architectures possible avec une délégation à Postgresql du travail de niveaux de zoom sur des données géographiques.

    Pour aller plus loin voir le support de présentation.


  • Notes suite au 4ème rendez-vous OpenStack à Paris

    2013/06/27 by Paul Tonelli

    Ce 4ème rendez-vous s'est déroulé à Paris le 24 juin 2013.

    http://www.logilab.org/file/149646/raw/openstack-cloud-software-vertical-small.png

    Retours sur l'utilisation d'OpenStack en production par eNovance

    Monitoring

    Parmi les outils utiles pour surveiller des installation OpenStack on peut citer OpenNMS (traps SNMP...). Cependant, beaucoup d'outils posent des problèmes, notamment dans le cadre de l’arrêt ou de la destruction de machines virtuelles (messages d'erreur non souhaités). Il ne faut pas hésiter à aller directement se renseigner dans la base SQL, c'est souvent le seul moyen d'accéder à certaines infos. C'est aussi un bon moyen pour exécuter correctement certaines opérations qui ne se sont pas déroulées convenablement dans l'interface. L'utilisation possible de SuperNova est recommandée si on utilise plusieurs instances de Nova (multi-environnement).

    Problèmes durant les migrations

    Citation : "plus on avance en version, mieux la procédure se déroule".

    La pire migration a été celle de Diablo vers Essex (problèmes d'IPs fixes qui passent en dynamique, problèmes de droits). Même si tout semble bien se passer sur le moment, faire un redémarrage des nœuds hardware / nœud(s) de contrôle est recommandé pour vérifier que tout fonctionne correctement après le redémarrage.

    Si on veut supprimer un nœud qui fait tourner des machines, une commande existe pour ne pas recevoir de nouvelles machines (en cas de panne matérielle par exemple).

    Afin d'avoir de la redondance, ne pas utiliser les nœuds hébergeant les machines à plus de 60% permet d'avoir de la place pour héberger des machines déplacées en cas de panne / disparition d'un des nœuds nova-compute.

    Au niveau migration, ce qui est bien documenté pour KVM est la migration avec du stockage partagé ou 'live storage' (le système de fichier contenant le disque de la machine est disponible sur la source de la machine et sur la destination). Il existe un second mode, avec migration par 'block' qui permet de migrer des disques s'ils ne sont pas sur un système de fichier partagé. Ce second mécanisme a été présent, puis rendu obsolète, mais une nouvelle version semble aujourd'hui fonctionnelle.

    À propos de la fonction terminate

    La fonction terminate détruit définitivement une machine virtuelle, sans possibilité de retour en arrière. Il n'est pas évident pour une personne qui commence sur OpenStack de le comprendre : elle voit souvent ce bouton comme "juste" éteindre la machine. Pour éviter les gros problèmes (tuer une machine client par erreur et sans retour en arrière possible), il existe 2 solutions :

    Pour les admins il existe un paramètre dans la configuration d'une instance :

    UPDATE SED disable_terminate '1'
    

    Pour les autres (non-admins), on peut utiliser une fonction de verrouillage (nova lock) d'une machine afin d'éviter le problème. (Les deux utilisent le même mécanisme).

    Token

    Les tokens servent à authentifier / autoriser une transaction sur les différentes versions d'OpenStack. Il est important que la base qui les stocke soit indexée pour améliorer les performances. Cette base grossit très vite, notamment avec grizzly où les tokens reposent sur un système PKI. Il est utile de faire une sauvegarde régulière de cette base avant de la flusher (pour permettre à un client de récupérer un ancien token notamment).

    Espace de stockage

    Ce n'est pas conforme aux bonnes pratiques, mais avoir juste un /var énorme pour le stockage fonctionne bien, notamment quand on a besoin de stocker des snapshots de machines Windows ou de grosses machines.

    Ceph

    https://www.logilab.org/file/149647/raw/logo.png

    Spécial citation: "c'est du libre, du vrai".

    Ceph est un projet permettant d'avoir un stockage redondant sur plusieurs machines, et offrant trois opérations principales : get, put, delete. Le système repose sur l'utilisation par le client d'une carte, fournie par les serveurs ceph, qui lui permet de trouver et de récupérer facilement un objet stocké.

    Le pilote de stockage virtualisé est parfaitement fonctionnel et tourne déjà en production. Ce pilote permet d'utiliser Ceph comme périphérique de stockage pour des machines virtuelles. Il existe un remplacement (Rados Gateway Daemon) qui implémente l'interface swift pour OpenStack et permet d'utiliser Ceph en backend. Ce pilote est qualifié de stable.

    Le pilote noyau (librbd) permettant de voir du stockage Ceph comme des disques est encore en développement, mais devrait fonctionner à peu près correctement si le noyau est >= 3.8 (3.10 conseillé).

    Performances

    En écriture, une division par deux des performances est à prévoir par rapport à une utilisation directe des disques (il faut que les N copies ait été stockées avant de valider la transaction). En lecture, Ceph est plus rapide vu l'agrégation possible des ressources de stockage.

    Traduction de Openstack

    La communauté cherche des gens motivés pour traduire le texte des différents outils Openstack.

    Neutron (anciennement Quantum)

    Pas mal de travail en cours, la version Havana devrait avoir la capacité de passer mieux à l'échelle et permettre la haute disponibilité (ça fonctionne toujours même quand une des machines qui hébergent le service plante) pour tout ce qui est DHCP / L3.

    Sur l'organisation d'une communauté OpenStack en France

    Différents acteurs cherchent actuellement à se regrouper, mais rien n'est encore décidé.


  • PME et simulation numérique : deux mondes qui peinent à se rejoindre

    2013/06/11 by Olivier Cayrol

    Ce matin, j'ai assisté aux Rencontres INRIA Industries qui portaient sur le thème "Modélisation, simulation et calcul intensif". Y était notamment présenté l'initiative HPC-PME dont l'objet est de faciliter l'accès des PME au calcul hautes performances. Cette conférence a été pour moi l'occasion de formaliser mes réflexions sur les PME et leur recours à la simulation numérique.

    http://www.logilab.org/file/145959/raw/2013-HPC-PME.jpg

    HPC-PME : une initiative pour montrer aux entreprises l'apport du calcul hautes performances

    L'initiative HPC-PME est portée par l'INRIA, le GENCI et OSEO. Elle se propose d'accompagner des PME afin de leur montrer en quoi le calcul hautes performances peut leur être utile pour innover, gagner en compétitivité, et finalement identifier des leviers de croissance. Elle décline ses actions selon quatre axes :

    • la formation et le partage de bonnes pratiques,
    • l'accès à des ressources de calcul pour montrer l'utilité du calcul hautes performances,
    • le soutien d'experts issus de la recherche publique, qui vont transférer leurs compétences en calcul hautes performances,
    • l'intégration dans des dispositifs de financement de l'innovation.

    L'accompagnement classique d'une PME consiste à identifier avec elle quels sont les points sur lesquels la simulation numérique peut lui apporter quelque chose, à dimensionner les besoins en calcul nécessaires à ces simulations, à l'aider à porter ses codes de simulation vers des machines de calcul hautes performances, et enfin à effectuer, sur ces machines, un cas de calcul typique.

    https://www.logilab.org/file/145960/raw/Screenshot%20from%202013-06-12%2014%3A38%3A43.png

    Après deux ans de travail, l'initiative HPC-PME a permis à 30 PME d'être accompagnées et de découvrir en quoi le calcul hautes performances peut les aider à gagner en compétitivité. Ces PME sont issues de domaines d'activités très divers (hydrologie marine, électronique, gestion de l'énergie, finance, etc.) et ont comme point commun d'être centrées sur un métier donné et de ne pas avoir, généralement, de compétences internes dans le domaine du calcul numérique.

    Convaincu depuis longtemps que la simulation numérique et l'utilisation intelligente de la puissance informatique peuvent aider les entreprises à gagner en compétitivité, je ne peux qu'être ravi d'une initiative telle que HPC-PME. Toutefois, elle ne me semble pas toujours convenir aux besoins d'une PME qui se pose la question d'un recours à la simulation numérique.

    Les besoins des PME : pouvoir, sans investissement, faire des calculs pas forcément complexes

    Lors des différentes conversations que j'ai pu avoir avec des dirigeants de PME, il m'est apparu que leur principale demande est de pouvoir effectuer très simplement des simulations en fournissant un jeu de données puis en cliquant sur un bouton. L'initiative HPC-PME a pour objectif de démontrer l'intérêt du calcul hautes performances et d'aider les PME à acquérir les compétences leur permettant de mettre en œuvre des solutions de HPC. Or, la plupart des PME :

    • ne souhaitent pas mettre en place en interne une solution de calcul hautes performances (achat, configuration, maintenance),
    • ne désirent pas acquérir en interne les compétences leur permettant d'utiliser une solution de calcul hautes performances,
    • n'ont pas réellement besoin des performances extrêmes apportées par l'initiative HPC-PME (la Formule 1 de la simulation numérique), mais plutôt d'une solution solide, simple, et à coût d'entrée raisonnable (une bonne voiture haut de gamme suffit),
    • n'ont pas une demande continue leur permettant d'amortir un investissement en calcul numérique.

    Les PME ont généralement une expertise métier forte, c'est là leur facteur différenciant. Mais elles n'ont, pour la majorité d'entre elles, aucune compétence en analyse numérique ou en informatique. Attendu qu'elles n'ont que peu de calculs à effectuer, il leur est surérogatoire d'internaliser ces compétences.

    Partant de ce constat, je pense sincèrement que la meilleure façon pour une PME d'avoir accès au calcul numérique serait de disposer d'une plateforme dont l'accès est facturé à l'utilisation et qui lui permet de :

    • définir un cas de calcul en termes métier,
    • avoir accès à des ressources de calcul sur lesquelles les codes de calcul sont installés et configurés,
    • lancer en un clic le cas de calcul sur une ressource de calcul offrant des performances suffisantes,
    • pouvoir obtenir de l'aide de la part d'experts numériciens connaissant les codes de calcul (en cas de problème numérique ou de modélisation),
    • offrir des fonctionnalités de partage des cas de calcul selon des règles de sécurité strictes et entièrement contrôlables (typiquement pour faire appel à un expert numéricien, montrer ses résultats au client final ou faire travailler un fournisseur).

  • Retour OSDC 2012 - présentation mercurial DVCS

    2012/12/05 by Pierre-Yves David

    À la mi-octobre, j'ai participé à la conférence OSDC 2012 à Paris. Le but de cette conférence est de permettre à des développeurs de différentes communautés de se rencontrer dans une ambiance chaleureuse. De fait, j'ai découvert un certain nombre de projets et de pratiques intéressants.

    http://act.osdc.fr/osdc2012fr/css/logo.png

    Le samedi, j'ai découvert des outils javascript mettant l'accent sur les modèles de données comme AngularJS ou BackBone, Une présentation rapide du langage Go, le très prometteur portage des outils GCC sur Windows nommé MinGW ainsi que les nouveautés de GCC 4.8. La journée s'est conclut sur des présentations éclairs dont je retiendrai surtout la perversité des opérateurs secrets en Perl et le livre Javascript Éloquent intégralement en HTML qui en profite donc pour inclure exemples et exercices interactifs au fil du contenu.

    Le dimanche matin j'ai ouvert le bal en présentant mes travaux actuels dans le DVCS Mercurial: l'Évolution de Changeset (PDF de la présentation). Ce concept permet aux développeurs de découvrir la réécriture d'historique de manière simple et sûre. Les utilisateurs avancés ont accès de leur côté à des processus de travail et de revue encore inédits dans le monde des DVCS. Ma présentation fut suivie d'une introduction à la découverte automatique de bugs grâce à la bisection dans les DVCS.


    Changesets Evolution : Mercurial secoue le monde du dvcs par Pierre-Yves David

    La journée s'est poursuivie avec une présentation du langage Haskell, de la bibliothèque de visualisation sigmajs et la spécification SPORE apportant un peu d'espoir dans les spécifications de services Web REST.


  • Retour Agile Tour Nantes 2012 - présentation et pistes à explorer

    2012/12/04 by Arthur Lutz

    Nous utilisons les méthodes agiles depuis la création de Logilab. Nous avons parfois pris des libertés avec le formalisme des méthodes connues, en adaptant nos pratiques à nos clients et nos particularités. Nous avons en chemin développé nos propres outils orientés vers notre activité de développement logiciel (gestion de version, processus sur les tickets, intégration continue, etc).

    https://www.logilab.org/file/113044?vid=download

    Il est parfois bon de se replonger dans la théorie et d'échanger les bonnes pratiques en terme d'agilité. C'est pour cette raison que nous avons participé à l'étape nantaise de l'Agile Tour.

    Logiciels libres et agilité

    Plutôt que d'être simples spectateurs, nous avons présenté nos pratiques agiles, fortement liées au logiciel libre, dont un avantage indéniable est la possibilité offerte à chacun de le modifier pour l'adapter à ses besoins.

    Premièrement, en utilisant la plate-forme web CubicWeb, nous avons pu construire une forge dont nous contrôlons le modèle de données. Les processus de gestion peuvent donc être spécifiques et les données des applications peuvent être étroitement intégrées. Par exemple, bien que la base logicielle soit la même, le circuit de validation des tickets sur l'extranet n'est pas identique à celui de nos forges publiques. Autre exemple, les versions livrées sur l'extranet apparaissent directement dans l'outil intranet de suivi des affaires et de décompte du temps (CRM/ERP).

    Deuxièmement, nous avons choisi mercurial (hg) en grande partie car il est écrit en python ce qui nous a permis de l'intégrer à nos autres outils, mais aussi d'y contribuer (cf evolve).

    Notre présentation est visible sur slideshare :

    http://www.logilab.org/file/113040?vid=download

    ou à télécharger en PDF.

    Behaviour Driven Development

    Le BDD (Behaviour Driven Development) se combine avec des tests fonctionnels haut niveau qui peuvent être décrits grâce à un formalisme syntaxique souvent associé au langage Gherkin. Ces scénarios de test peuvent ensuite être convertis en code et exécutés. Coté Python, nous avons trouvé behave et lettuce. De manière similaire à Selenium (scénarios de test de navigation Web), la difficulté de ce genre de tests est plutôt leur maintenance que l'écriture initiale.

    https://www.logilab.org/file/113042?vid=download

    Ce langage haut niveau peut néanmoins être un canal de communication avec un client écrivant des tests. À ce jour, nous avons eu plusieurs clients prenant le temps de faire des fiches de tests que nous "traduisons" ensuite en tests unitaires. Si le client n'est pas forcément prêt à apprendre le Python et leurs tests unitaires, il serait peut-être prêt à écrire des tests selon ce formalisme.


  • Logilab à PyConFR 2012 - compte rendu

    2012/10/09 by Alain Leufroy
    http://awesomeness.openphoto.me/custom/201209/4ed140-pycon3--1-of-37-_870x550.jpg

    Logilab était à la conférence PyConFR qui a pris place à Paris il y a deux semaines.

    Nous avons commencé par un sprint pylint, coordonné par Boris Feld, où pas mal de volontaires sont passés pour traquer des bogues ou ajouter des nouvelles fonctionnalités. Merci à tous!

    Pour ceux qui ne connaissent pas encore, pylint est un utilitaire pratique que nous avons dans notre forge. C'est un outil très puissant d'analyse statique de scripts python qui aide à améliorer/maintenir la qualité du code.

    Par la suite, après les "talks" des sponsors¸ où vous auriez pu voir Olivier, vous avons pu participer à quelques tutoriels et présentations vraiment excellentes. Il y avait des présentations pratiques avec, entre autres, les tests, scikit-learn ou les outils pour gérer des services (Cornice, Circus). Il y avait aussi des retours d'information sur le processus de développement de CPython, le développement communautaire ou un supercalculateur. Nous avons même pu faire de la musique avec python et un peu d'"embarqué" avec le Raspberry Pi et Arduino !

    Nous avons, avec Pierre-Yves, proposé deux tutoriels d'introduction au gestionnaire de versions décentralisé Mercurial. Le premier tutoriel abordait les bases avec des cas pratiques. Lors du second tutoriel, que l'on avait prévu initialement dans la continuité du premier, nous avons finalement abordé des utilisations plus avancées permettant de résoudre avec énormément d'efficacité des problématiques quotidiennes, comme les requêtes sur les dépôts, ou la recherche automatique de régression par bissection. Vous pouvez retrouver le support avec les exercices .

    Pierre-Yves a présenté une nouvelle propriété importante de Mercurial: l'obsolescence. Elle permet de mettre en place des outils d'édition d'historique en toute sécurité ! Parmi ces outils, Pierre-Yves a écrit une extension mutable-history qui vous offre une multitude de commandes très pratiques.

    La présentation est disponible en PDF et en consultation en ligne sur slideshare. Nous mettrons bientôt la vidéo en ligne.

    http://www.logilab.org/file/107770?vid=download

    Si le sujet vous intéresse et que vous avez raté cette présentation, Pierre-Yves reparlera de ce sujet à l'OSDC.

    Pour ceux qui en veulent plus, Tarek Ziadé à mis à disposition des photos de la conférence ici.


  • Rencontre LLVM à l'IRILL

    2012/09/27 by Damien Garaud
    IRILL-logo LLVM-logo

    L'IRILL , Initiative de Recherche et Innovation sur le Logiciel Libre, organisait une rencontre LLVM mardi 25 septembre à Paris dans les locaux de l'INRIA Place d'Italie dans le 13e arrondissement. Les organisateurs, Arnaud de Grandmaison, Duncan Sands, Sylvestre Ledru et Tobias Grosser ont chaleureusement accueilli environ 8 personnes dont 3 de Logilab.

    L'annonce de l'IRILL indiquait une rencontre informelle avec une potentielle Bug Squashing Party sur Clang. Nous n'avons pas écrasé d'insectes mais avons plutôt discuté: discussions techniques, petits trolls, échanges de connaissances, d'outils et d'expériences accompagnés de bières, sodas, gâteaux et pizzas (et une salade solitaire et orpheline qui n'a finie dans le ventre de personne contrairement aux pizzas mexicaines ou quatre fromages).

    LLVM (Low Level Virtual Machine) est un projet développé depuis une dizaine d'années qui propose une collection d'outils et de modules facilement réutilisables pour construire des logiciels orientés langages : interpréteurs, compilateurs, optimiseurs, convertisseurs source-to-source...

    Depuis l'étage d'entrée du code dans le compilateur (ou frontend), en passant par l'optimiseur indépendant de la plate-forme, jusqu'à la génération de code machine (backend) et ce, pour plusieurs architectures (X86, PowerPC, ARM, etc.), le choix de son design en fait un outil tout à fait intéressant. Parmi ces frontends, il y a le fameux Clang (C/C++, Objective-C), GHC (Haskell). Et le projet dragonegg permet de l'utiliser comme plug-in à GCC et donc de bénéficier des différents frontends GCC (Ada, Fortran, etc.).

    De nombreux outils se sont construits autour du framework LLVM : LLDB un débugger, vmkit une implémentation de la machine virtuelle Java et .NET ou encore polly, un projet de recherche dont Tobias est l'un des deux co-fondateurs, qui a pour objectif d'optimiser un programme indépendamment du langage via des polyhedral optimizations.

    Les principaux contributeurs à ce jour sont Apple, Google, des contributeurs "individuels" dont Duncan Sands, suivis par des laboratoires de recherche et autres. Voir l'article de Sylvestre sur "Who is in control of LLVM/Clang ?".

    La clef de voûte de LLVM est sa représentation intermédiaire (IR pour Intermediate Representation). C'est une structure de données qui représente sous forme SSA (Single Static Assignment) les flux de données et de contrôle. Cette forme est plus "haut-niveau" et plus lisible que du code assembleur, elle comporte certaines informations de type par exemple. Elle constitue le pivot de l'infrastructure LLVM : c'est ce que produisent les frontends comme Clang, qui est ensuite passée aux optimiseurs de LLVM et est ensuite consommée par les backends dont le rôle est de les transformer en code machine natif.

    En voici un exemple en C:

    int add(int a)
    {
        return a + 42;
    }
    

    La représentation intermédiaire est donnée via Clang :

    $> clang -S -emit-llvm add_function.c -o add_function.ll

    L'extension *.ll désigne des "fichiers IR" et le résultat donne:

    define i32 @add(i32 %a) nounwind uwtable {
      %1 = alloca i32, align 4
      store i32 %a, i32* %1, align 4
      %2 = load i32* %1, align 4
      %3 = add nsw i32 %2, 42
      ret i32 %3
    }
    

    Cette représentation peut ensuite être bitcodée, assemblée ou compilée. Voir les différentes commandes LLVM pour assembler, désassembler, optimiser, linker, exécuter, etc.

    Une autre utilisation intéressante de cette infrastructure est l'utilisation de la bibliothèque Clang pour parser du code C/C++ afin de parcourir l'Abstract Syntax Tree (AST). Ceci offre notamment de belles possibilités d'introspection. Google a d'ailleurs rédigé un tutoriel sur les plugins Clang et ses possibilités via l'API de Clang, notamment la classe ASTConsumer. Il est possible de parcourir l'ensemble des constructeurs, de connaître la propriété d'une classe (abstraite ou non), parcourir les membres d'une classe, etc. Avant de partir, nous parlions de la possiblité de propager un changement d'API à travers toutes les bibliothèques qui en dépendent, soit la notion de patch sémantique.

    Nous avons aussi profité pour parler un peu du langage Julia ou de Numba.

    Pythonistes convaincus, nous connaissions déjà un peu Numba, projet de Travis Oliphant, contributeur NumPy et papa de SciPy. Ce projet utilise l'infrastructure LLVM pour compiler du byte-code Python en code machine (Just In Time compilation), en particulier pour NumPy et SciPy. Les exemples montrent comment passer d'une fonction Python qui traite un tableau NumPy à une fonction compilée Just In Time. Extrait issu d'un des exemples fournis par le projet Numba :

    from numba import d
    from numba.decorators import jit as jit
    
    def sum2d(arr):
        M, N = arr.shape
        result = 0.0
        for i in range(M):
            for j in range(N):
                result += arr[i,j]
        return result
    
    csum2d = jit(ret_type=d, arg_types=[d[:,:]])(sum2d)
    

    Oui, la fonction sum2d n'est pas optimale et très "naïve". Néanmoins, la fonction compilée va près de 250 fois plus vite ! Numba utilise les bindings LLVM pour Python via llvm-py afin de passer du code Python, à l'Intermediate Representation pour ensuite utiliser les fonctionnalités JIT d'LLVM.

    Entre programmeurs de langages à typage statique, nous avons aussi parlé de C et d'Ocaml (dont il existe des bindings pour LLVM) et mentionné de beaux projets tels que PIPS et Coccinelle.

    Pour finir, nous savons maintenant prononcer Clang. On dit "klang" et non "cilangue". Nous avons appris que gdb avait son propre parser et n'utilisait pas le parser de GCC. Rappelons-le, l'un des grands avantages de LLVM & Clang face à GCC est sa modularité et la possibilité d'utiliser une des pierres qui forme l'édifice pour construire sa propre maison.

    Nous finissons ce billet par une citation. David Beazley disait lors de sa présentation à Eursoscipy 2012 :

    The life is too short to write C++.

    Certes. Mais qu'on le veuille ou qu'on le doive, autant se servir d'outils biens pensés pour nous faciliter la vie.

    Encore merci aux organisateurs pour cette rencontre et à la prochaine.

    Quelques références


  • Sprint PyLint @ PyConFr 2012

    2012/08/20 by Sylvain Thenault

    Un sprint PyLint est organisé dans le cadre de la conférence PyConFR, les 13 et 14 septembre à Paris. Si vous voulez améliorer PyLint, c'est l'occasion : venez avec vos bugs et repartez sans !

    Les débutants sont bienvenus, une introduction au code de Pylint sera réalisée en début de sprint. Une expérience avec le module ast de la librairie standard est un plus.

    Croissants et café offerts par l'organisation, merci de vous inscrire pour faciliter la logistique. Voir avec Boris pour plus d'informations (merci à lui !)


  • 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)


  • Mêlée numérique 2012: État de l'art Big Data

    2012/05/03 by Sylvain Thenault
    http://www.logilab.org/file/92705?vid=download

    J'ai passé ce jeudi 26 avril à la Mêlée numérique à Toulouse.

    Après une mini-conf d'une heure sur l'état de l'art de l'Open Data, j'ai suivi l'après midi "état de l'art Big Data" au même format.

    Big Data vu par SGI

    Ma première surprise a été d'apprendre où était caché SGI (vous vous rappelez peut-être les postes Indigo qu'on trouvait pour faire du graphisme et de l'animation...) depuis tout ce temps : et bien non, ils ne sont pas morts mais montent des calculateurs pour des grands comptes. Le premier intervenant était donc M. Carsalade, responsable infrastructure chez SGI, qui a pris quelques exemples d'applications et d'infrastructures "Big Data" (petabytes de données) menées par SGI.

    Parmi les applications citées : calculateurs chez NOAA (sorte de Météo France aux US) ou Total (analyse des sols), Cosmos Project (15 tera de ram...), génomiques

    SGI déploie par ex. :

    • 500 000 serveurs SGI chez Amazon pour S3/eC2, site web, AWS...
    • 300 000 serveurs SGI chez Microsoft pour Live Search (Bing, Exchange, MSN, etc.)

    La technologie est souvent basée sur HADOOP, qui permet la recherche en parallèle sur un cloud, basée sur le principe map / reduce initiée par Google.

    On note l'évolution des technologies dans le temps et par volume croissant:

    • OLTP (données structurées),
    • data warehouse (données essentiellement structurées),
    • Big Data (données essentiellement non structurées)

    Il conclut que Big Data, c'est :

    • la capacité de stockage de données, et celle de l'agrandir au fur et à mesure du besoin,
    • travailler sur ces données (HADOOP), les analyser et les visualiser,
    • mais aussi archiver ces données, problématique souvent ignorée au premier abord mais pourtant nécessaire.

    Big Data vu par une PME spécialisée

    La présentation suivante de M.Royer (Datasio) est un peu plus technique.

    Pour commencer, une liste des sources de données problématiques potentielles (i.e. la production ne s'arrête pas) :

    • production par des réseaux d'observation autonome (capteurs météo, GPS, RFID, balises Argos...),
    • données dépendantes d'une communauté d'utilisateurs et d'individus instrumentés,
    • données produites plus vite qu'on ne les traite,
    • "on verra le traitement plus tard".

    Synthèse de ces problèmes : les "3 V" du Big Data: Volume / Variété / Vélocité.

    Les techniques autour de Big Data promettent de :

    • faciliter la collecte et l'aggrégation (mesurer les opérations, acquérir tous les flux possibles, stocker les mesures brutes)
    • valoriser le capital de données (découvrir après coup des opportunités inexploitées, outils de fouille adaptés aux gros volumes, extraire et distiller l'information)

    Il revient sur HADOOP en quelques mots :

    • solution Open Source, issu de la fondation Apache,
    • à l'initiative de Yahoo via un essaimage Hortonworks
    • c'est un projet en maturation, avec une communauté active, mais des branches de code variées,
    • constitué d'un système de fichier distribué avec redondance (parallélisation des données) et possibilité map / reduce (parallélisation des tâches à effectuer sur les données)

    Si Big Data est un nouveau terme pour une problématique qui n'est pas nouvelle, une différence liée à la technique map / reduce les traitements sont effectués sur les serveurs qui hébergent les données au lieu de pousser les données vers un calculateur. Attention au fait cependant que pour fonctionner, les algorithmes doivent fonctionner de manière indépendante sur un sous-ensemble indéterminé de données (donc finalement indépendamment sur chaque "donnée"). Enfin, on se concentre sur l'efficience de la création et de la lecture des données, à l'inverse des bases de données traditionnelles qui se concentrent également sur la mise à jour et la suppression.

    Je ne sais pas s'il y avait une conclusion, la présentation a été abrégée faute de temps.

    Big Data vu par Météo France

    La dernière présentation était celle de M.Beuraud de Météo France dont la problématique, pas simple mais à laquelle nous sommes tous sensibles, est la prévision numérique du temps.

    Il note tout d'abord que la qualité des prévisions a augmenté : la qualité d'une prévison à 48h aujourd'hui vaut prévision à 24h il y a 15 ans en lien avec l'augmentation des performances du centre de calcul HPC de Météo France à Toulouse (évolution matérielle tous les 3 ans) :

    • 2 GFlops en 1991 (date de l'ouverture du centre), basé sur des machines Cray 2,
    • 100 TFlops en 2009, basé sur des machines NEC SX9

    Le volume de données étudiées est maintenant beaucoup plus important, principalement du fait de la constellation de satellites qui s'est développée et qui produit un volume beaucoup plus important que les mesures conventionnelles (au sol). On a vu un "déluge de données" satellitaires depuis 2010. D'un point de vue stockage, le site est passé de 20Go en 1991 à plusieurs pétaoctets aujourd'hui.

    De par les différentes contraintes extérieures (données à fournir aux clients), une prévision à 24h doit être faite en 25 minutes. De plus, la puissance de calcul nécessaire augmente sans cesse notamment à cause des facteurs suivants (en plus du volume de données à analyser qui augmente) :

    • maille de plus en plus petite,
    • couplage de modèles de plus en plus nombreux,
    • prévision ensembliste : on lance X fois le même modèle avec des entrées différentes pour voir la stabilité de la prédiction.

    A noter qu'ici, on n'est pas dans des technos de type HADOOP.

    Il conclut que le volume de données à traiter va continuer à grandir, et que la gestion des données est l'enjeu majeur de la décennie qui s'ouvre.

    Conclusion

    J'ai été surpris de voir l'angle d'approche pour la présentation d'une thématique Big Data, qui était pour moi (novice je l'avoue) plus liée aux technologies Web. J'ai finalement trouvé que c'était intéressant de remettre ça avec cette perspective, et ainsi de replacer ce que recouvrent finalement les mots Big Data. Encore un grand mot qui veut tout et rien dire quoi :p


  • Mélée numérique 2012: État de l'art Open Data

    2012/04/27 by Sylvain Thenault
    http://www.logilab.org/file/92705?vid=download

    J'ai passé ce jeudi 26 avril à la Mélée numérique à Toulouse.

    J'y ai assisté à une mini-conf d'une heure sur l'état de l'art de l'Open Data. Comme d'habitude, je conseillerais plutôt, lors des salons de ce type, d'aller voir les conférences sur des thèmes qui vous sont inconnus, sous peine de ne pas apprendre grand chose. C'est resté pas trop mal, et voici ce que j'ai retiré de cette présentation conjointe de Bluenove, et Inno3.

    Data, c'est quoi exactement ?

    Dans le cadre de l'Open Data la donnée est le matériaux brute. C'est une valeur, une observation. Ce n'est pas une information, qui recoupe et interprète plusieurs données.

    Le recoupement de données permet de créer des informations de valeurs. Cependant certaines données n'ont pas vocation à être ouvertes (ex. données stratégiques, personnelles, défense).

    Qui sont les acteurs de l'Open Data ?

    On distingue :

    Qui a ouvert ses données ?

    En France : Étalab, 16 ministères, 5 administrations publiques, 2 régions, 5 départements, 11 métropoles, 7 municipalités, 3 grandes entreprises (réseau férré, sncf, la poste), 4 initiatives culturels, PS...

    Dans le monde: 28 pays, environ 120 localités de toutes tailles. On voit se former des initiatives continentales,

    Pour quels résultats ?

    • Un nouveau type d'information (NR issu d'une collaboration journaliste/développeur/graphiste), plus ou moins couvert sous le terme "Data viz" (eg OWNI)
    • Des applications diverses, parfois issues de concours (eg application téléphone Tourisme 71)

    Quels sont les freins et incitations ?

    Il y a une incitation/obligation venant de l'Europe (2003) et de l'état (2006) pour les acteurs publics, les acteurs privés délégataires d'un service public ou monopolistiques. On peut ajouter les modèles économiques basés sur la société de l'information (eg http://www.openstreetmap.org/ qui crée des données ouvertes collaborativement depuis 2006)

    Les freins viennent :

    • des données non diffusables,
    • d'une cohabitation parfois difficile avec Loi informatique et liberté / CNIL (le recoupement de plusieur sources peut finir par redonner des données "personnelles").

    De plus cette incitation à la transparence crée nouveaux rapport entre secteur public et privé (je ne m'en plaindrai pas personnellement :p ).

    Quels droits / quelles licences sur les données ?

    Rappel : la propriété intellectuelle recrée une notion similaire à la propriété matérielle mais sur des oeuvres. Les données ne sont pas soumise à la propriété intellectuelle. Les données originelles, ainsi qu'une base de données à forte valeur ajoutée, ou encore les signes distinctifs (marque, nom de domaine, logo, etc) sont considérés ou considérables comme des oeuvres.

    Il faut donc une gestion stratégique des différents droits de propriété intellectuelle. Que faut-il partager ou retenir ? Quel est l'encadrement souhaité ? Copyleft (eg GPL) ou non ? Compatibilité entre jeux de données ?

    Aujourd'hui on a comme licenses pour les données :

    • les licences basées sur le droit d'auteur (CC)
    • les licences basées sur la loi de 1978 (droit public en france, uniquement pour collectivité, pas de propriété intellectuelle) (LIP et APIE)
    • les licences spécialisées (ODBL, PDDL, ODC-By créées par Open knowledge foundation)
    • les licences dédiées (Licence Ouverte)

    En France (dans l'administration publique ?) l'ODBL et la Licence Ouverte sont principalement utilisées.

    En Europe et à l'étranger, on trouve plutôt l'ODBL, CC-0 et autres licences dédiées.

    Et l'Open Data dans l'entreprise ?

    Bluenove a mené une enquête auprès de grands groupes. Quelques résultats (l'intégralité est publiée dans un petit livre blanc dont j'ai un exemplaire) :

    • les bénéfices attendus de l'ouverture et de la réutilisation sont avant tout d'améliorer la satisfaction des clients, et en dernier lieu de se différencier de ses concurrents
    • les obstacles ressentis : le besoin de contrôler la réutilisation de ses données, la peur de donner l'accés à ses données aux concurents ou encore la frilosité à la réutilisation de données des autres (problème potentiel de fraicheur et/ou qualité des données)

    43 % des entreprises sondées disent qu'une réfléxion autour de l'Open Data est en cours évolution.

    Conclusion

    Aujourd'hui, les licences sont matures et ne posent plus vraiment problème. On peut espérer avoir rapidement plus de données et d'acteurs dans l'Open Data. Cependant dans le public comme dans le privé une difficulté est d'encadrer la production : motiver la production de données, accueillir les résultats et gérer la diffusion (qui a dit CubicWeb ? En toute objectivité :p ).

    NR: On notera l'absence de discussion autour des formats de publication de données notamment. Pour conclure, j'aurais plutôt appelé ça état les lieux que état de l'art, même si ça reste un effort de synthèse appréciable.


  • OpenData à Nantes: agrégateur des événements culturels

    2011/12/12 by Arthur Lutz

    Jeudi 8 décembre 2011 nous avons participé à la réunion de travail sur l'ouverture des données événementielles.

    Problématique des licences

    Un premier problème est que la licence proposée par LiberTIC est la CreativeCommons CC-BY, alors que les producteurs de données n'ont souvent pas les droits sur toutes les données qu'ils diffusent (par exemple la photo d'illustration d'un concert). Ils auront donc du mal à les publier en totalité sous licence CC-BY. Espérons que la licence Creative Commons rentre dans les habitudes et que cela ne va pas trop freiner le projet.

    Aujourd'hui, l'utilisation ressemble à du Fair Use: on tolère la ré-utilisation de contenus protégés par le droit d'auteur car cela sert la diffusion de l'information.

    Nous nous sommes demandé s'il est possible de mélanger deux licences dans un flux de données ou s'il faut faire deux flux séparés mais liés.

    https://creativecommons.org/images/license-layers.png

    Problématique d'utilisation

    Un deuxième problème est que les réutilisateurs ne seront pas intéréssés si les données sont trop pauvres et qu'elles n'incluent pas d'image ou de vidéo. Il faut donc trouver un socle commun qui satisfasse les producteurs et les réutilisateurs.

    Import ou gros formulaires qui tâchent ?

    Vu la complexité du modèle de données qui a émergé des discussions (beaucoup de cas particuliers), il a été proposé de fournir un formulaire de saisie d'un événement. A notre avis, la saisie "manuelle" doit rester un cas exceptionnel (un acteur culturel n'ayant pas de site pour publier par exemple), au risque de n'être pour les producteurs qu'un enième site à renseigner lors de la publication de son agenda.

    Un exemple de bonnes pratiques est le très populaire GoodRelations qui offre un formulaire pour qu'un utilisateur qui n'a pas intégré le format à sa boutique en ligne puisse facilement générer son fichier et l'héberger chez lui, favorisant ainsi un modèle décentralisé calqué sur celui des moteurs de recherche.

    Formats

    Il nous semble donc important de se concentrer sur les formats standards qui pourraient être importés et exportés par la plateforme.

    En voici une liste non exhaustive:

    Lectures supplémentaires

    Cherchant à combiner des vocabulaires existants (afin de ne pas réinventer un format qui devra être traduit dans un autre vocabulaire pour être réutilisable) nous sommes tombés sur les articles suivants :

    http://cdn1.iconfinder.com/data/icons/transformers/network-connections.png http://cdn1.iconfinder.com/data/icons/transformers/Internet-Explorer.png http://cdn1.iconfinder.com/data/icons/transformers/entire-network.png

    Conclusion

    Il nous paraît important de ne pas se tromper dans les orientations choisies:

    • utiliser des formats standards et combiner l'utilisation de namespaces existants plutôt que d'inventer un nouveau format
    • proposer plusieurs formats d'export pour différentes utilisations (json, ical, etc) quitte à ne pas inclure tout le contenu disponible si le format ne s'y prête pas
    • ne pas créer une API de plus et choisir de privilégier les standards du web sémantique en publiant du RDF et si possible en fournissant un accès SPARQL
    • préférer la publication distribuée des données par leurs producteurs et leur agrégation par la plate-forme plutôt que d'attendre des producteurs qu'ils remplissent un formulaire de plus.

    Nous attendons avec impatience la suite des travaux. Selon LiberTIC la plateforme sera developpée en logiciel libre avec des outils collaboratifs pour piloter le projet.

    CubicWeb est une plateforme disponible en logiciel libre qui a déjà fait ses preuves et a été conçue pour développer des applications du type de l'aggrégateur décrit ci-dessus: import et export des données sous différents formats, utilisation des technologies standards du web sémantique. Nous espérons que ceux qui auront à réaliser l'agrégateur choisiront CubicWeb comme base technique pour ce projet.


  • Rencontre Open Data à Nantes: Enjeux et opportunités pour le secteur culturel

    2011/11/17 by Arthur Lutz

    Nous étions présents à l'évenement organisé par Stereolux et Libertic consacré à l'OpenData dans le domaine de la culture à Nantes. Voici un court compte rendu des points que nous avons retenus de ces présentations.

    Présentation générale de l'OpenData par Libertic

    Il existe sur la toile assez d'articles sur l'Opendata pour qu'il ne nous semble pas nécessaire d'en donner une description, mais nous tenons à souligner que l'OpenData n'est pas simplement une mise à disposition des informations. Pour que des données puissent être qualifiées d'ouvertes, il faut qu'elles respectent une dizaine de principes parmi lesquels l'accessiblité, l'exploitabilité (données brutes), et la la réutilisablitié (licence).

    https://libertic.files.wordpress.com/2010/02/logo-libertic.png?w=300&h=180

    Claire Gallon a cité plusieurs exemples d'OpenData dans le domaine culturel :

    • la mise à disposition de données sur la fréquentation d'un musée permet de développer un service qui donnera la meilleure heure pour visiter ce musée. Voir When Should I visit Tate Modern
    • Marseille-Provence 2013 (capitale culturelle européenne) ouvre ses données et attend que les acteurs écrivent des applications (mobiles notamment).

    Un idée importante est que le service public doit s'adresser au plus grand nombre et ne peut pas consacrer ses ressources à la mise en place de services de niche. La mise à disposition des données permet à des tiers d'occuper ces niches.

    En conclusion, Claire Gallon insiste sur la nécessité d'inclure la gestion de la communauté dans les démarches d'ouverture des données. La prochaine priorité des acteurs de l'OpenData sera la coproduction, à la fois pour l'écriture des applications et pour l'amélioration des données.

    Présentation du projet data.bnf.fr par Romain Wenz

    http://data.bnf.fr/data/logo-bnf.gif http://data.bnf.fr/data/logo-data.gif

    Romain Wenz de la Bibliothèque nationale de France a présenté http://data.bnf.fr sous l'angle de l'ouverture : l'ouverture à un public différent, l'ouverture à un mode de recherche différent (on cherche sur internet avant d'aller en bibliothèque) et l'ouverture sur les reseaux sociaux où le public partage des références à des contenus qu'il apprécie (twitter, facebook, etc.). Cette ouverture passe forcément par un web indexable, où l'on peut communiquer facilement une URL d'un contenu (exit les portails de recherche avec des sessions et variable http). Si un site n'est pas indexable, son contenu pourra être trouvé en s'y connectant directement, mais celui-ci restera dans le web "invisible" ou "profond".

    Romain Wenz a insisté sur l'Importance des technologies utilisées : d'un coté les strandards ouverts et formalisés par le W3C, notamment en terme de web sémantique (RDF, RDFa, opengraph, schema.org, etc.) et de l'autre l'utilité de s'appuyer sur du logiciel libre. Dans le cas de http://data.bnf.fr il s'agit de CubicWeb.

    Présentation des collaborations entre Wikimedia France et des institutions publiques à Toulouse

    https://upload.wikimedia.org/wikipedia/commons/thumb/4/41/Commons-logo-en.svg/75px-Commons-logo-en.svg.png

    La transition entre la BnF et Wikimedia est facile : Wikisource (bibliothèque de livres libres de droits) a signé un partenariat avec Gallica qui lui a fourni des numérisations de livres tombés dans le domaine public.

    Wikimedia France a présenté deux projets réussis en coproduction avec des institutions Toulousaines :

    • le projet Phoebus a donné accès aux archives du Muséum de Toulouse à des bénévoles
    • la communauté Wikimedia Commons a participé à l'enrichissement des metadonnées du fond consacré au photographe Eugène Trutat.

    Présentation OpenData par la mairie de Nantes Métropole

    http://nantes.fr/webdav/site/nantesfr/shared/fileadmin/images/Puces/autrespuces/logo64_queue.png

    Frédéric Vasse a briévement présenté la démarche de la Ville de Nantes en matière d'OpenData. Le lancement de la plateforme aura lieu lundi prochain à la Cantine Numérique de Nantes. Selon lui, l'objectif de Nantes est de réussir la coproduction avec les acteurs du territoire.

    Conclusion et ouverture sur un projet concret d'OpenData pour les acteurs culturels

    Libertic a conclu en proposant aux acteurs culturels un projet d'aggrégateur d'informations sur les événements culturels à Nantes. Nous espérons pouvoir vous donner prochainement plus d'informations sur ce projet.

    Autre compte rendu (prises de notes) : http://www.scribd.com/doc/72810587/Opendata-Culture


  • Pourquoi il faudrait faire du Javascript coté serveur

    2010/10/20 by Arthur Lutz

    Description de la présentation sur le site de Paris Web 2010: ici.

    Quentin Adam voudrait que l'on fasse plus de javascript coté serveur. Un des principaux avantages du javascript server side est que il n'est pas nécessaire de traduire ces structures de données entre plusieurs languages de programmation.

    http://www.bewebmaster.com/bewebmaster/icons/JavaScript.png http://a3.twimg.com/profile_images/90410047/clouds2_normal.jpg

    Une des limites à cette adoption est que les moteurs de javascripts ne font pas de DOM (ca c'est le boulot du navigateur), du coup pas de jquery, mootools ou dojo (high level javascript)>. Par conséquent les développeurs javascript vont avoir des difficultés pour coder en server side. Certaines librairies sont en train de prendre en compte cet environnement limité.

    Quand on fait du javascript coté serveur, on peut considérer les requêtes comme des websockets, ce qui va être avantageux en terme de performances (par exemple lorsque le serveur reçoit deux requêtes identiques, quand la réponse est prête on renvoie deux fois la même chose).

    Voici quelques outils que Quentin Adam recommande ou mentionne :

    • Ape - Ajax Push Engine - http://www.ape-project.org Mettre du javascript dans un module apache. Coté client on a du mootols pour faire du développement.
    • Node.js http://www.nodejs.org très adopté par la communauté ruby. Node.js es apparu au moment de l'émergence de v8. Par contre celui-ci n'est pas très stable, la documentation n'est pas très complète, mais il y a beaucoup de "recettes" sur le web.
    • CommonJS http://www.commonjs.org/ est une librairie qui a l'avantage d'être en cours de standardisation.
    • Jaxer http://jaxer.org/ est une sorte de firefox embarqué dans un module apache, ce qui est un peu trop lourd mais son existence mérite d'être mentionnée.

    À Logilab, pour le développement de CubicWeb, nous penchons plutôt pour les développements des mécanismes asyncrones dans Twisted, mais cette présentation a le mérite de mettre en avant que d'utiliser javascript ne concerne pas uniquement les tweaks dans le navigateur.

    http://twistedmatrix.com/trac/chrome/common/trac_banner.png

  • Paris Web 2010 - Spécial typographie

    2010/10/20

    Suite de la première journée.

    Le lendemain, j'ai pu assister à La typographie comme outil de design (par David Rault) qui me semble être une sensibilisation indispensable à tout développeur web. Une introduction efficace et complète sur les familles de polices (classification VOX-ATypI) et les types d'effets produits sur le lecteur. Il faut voir la typographie comme l'équivalent de l'intonation à l'oral. La police apporte un autre contexte à la compréhension du texte. Pour finir, David Rault a parcouru les "web fonts" les plus connues tout en prenant soin de donner son avis d'expert ainsi que des détails historiques croustillants.

    Les organisateurs de Paris Web avaient ensuite judicieusement programmé La macrotypographie de la page Web (par Anne-Sophie Fradier). Après quelques explications historiques sur l'importance du support sur le format, plusieurs techniques de bases ont été présentées, comme par exemple l'usage des grilles pour la construction des pages. Celles-ci fixent un cadre à la créativité et permettent de respecter plus facilement des pauses visuelles pour retrouver un confort de lecture indispensable. L'interlignage doit être important (140% du corps), le fer à gauche et le drapeau à droite et un corps de texte suffisamment gros pour éviter des changements de taille de police intempestifs (qui risquent de "casser" la mise en page).

    Un des sujets intéressants mais souvent méconnu est le respect de la ligne de base dans la construction du flux vertical du texte dans un document. C'est justement sur ce principe et en se basant sur cet article que plusieurs personnes à Logilab ont commencé à implanter des "règles de rythmes" dans le framework CubicWeb lors d'un sprint en mai dernier. Dernier conseil à retenir d'une typographe, il faut donc toujours essayer de "retomber sur ses pattes" :-)

    Une question pertinente fut posée à la fin de la présentation sur la mode des "design fluides"; c'est-à-dire des mises en page calculées tout en proportion plutôt que fixées en pixels. La réponse donnée ne peut être absolue car ceci dépend essentiellement de la créativité et de l'originalité de l'auteur du site ; même si Anne-Sophie Fradier préconise quand même de garder le contrôle sur la largeur (la hauteur étant souvent imposée par le navigateur).

    Conclusion

    L'usage de WOFF, les nouveautés apportées par CSS3 et les effets rendus possibles par javascript vont permettre de créer un nouvel univers au texte et à sa mise en forme. Nous pouvons espérer que le confort de lecture et la lisibilité des textes vont devenir de véritables critères de qualité. Il me paraît aujourd'hui évident à l'issu de ces présentations que la typographie va petit à petit s'imposer comme une nouvelle compétence du web designer de demain.


  • Paris Web 2010 - Le texte et le web

    2010/10/20

    J'ai eu la chance d'assister à l'ensemble des conférences données à Paris Web sur le rôle du texte et de la typographie dans le web d'aujourd'hui.

    La présentation Le texte: parent pauvre du web ? (par Jean-Marc Hardy) rappela les points les plus pertinents sur l'usage des éléments textuels par rapport à l'image.

    Outre l'exemple classique sur les outils de référencement qui ne savent aujourd'hui utiliser que le texte brut d'une page (au grand dam des "flasheurs"), D'autres résultats d'études furent donnés:

    • le taux de suivi des liens publicitaires textuels (ceux de Google par exemple sont 10 fois plus efficaces que les bannières classiques qui ont un taux de suivi de 2‰).
    • des cartes de température montrent que les titres (surtout si ceux-ci sont inférieurs à 11 caractères) restent très structurants pour la lecture et le prise d'informations à la différence des images qui restent floues pour le cerveau pendant les premiers dixièmes de secondes
    • l'usage de phrases explicatives plutôt que des infinitifs vagues dans les boutons de formulaires rassurent l'utilisateur ѕur des étapes cruciales d'enregistrement.

    Un dernier contre-exemple étonnant fut donné au sujet d'une boutique en ligne qui en voulant mettre en valeur la corbeille d'achats par une image très colorée a provoqué l'effet inverse: un sentiment de rejet des utilisateurs qui croyaient voir alors une publicité ;-)

    Jean-Marc Hardy a évoqué brièvement le rôle du texte dans l'accessibilité mais a préféré laisser cette partie à d'autres orateurs de Paris Web (l'accessibilité étant à l'honneur cette année).

    J'aurais bien aimé avoir son avis sur l'esthétique souvent utilisée pour les sites dits Web2.0 qui se rapprochent finalement assez bien de ses recommandations.

    Le deuxième jour, j'ai particulièrement apprécié les sujets autour de la typographie et le rhythme des pages...


  • Retour sur paris-web 2010

    2010/10/18 by Adrien Di Mascio
    http://www.paris-web.fr/telechargements/logotype-paris-web.png

    La semaine passée avait lieu Paris-Web 2010. C'était la 5ème édition de cet événement mais je n'avais pas eu l'occasion d'y assister les années précédentes.

    Tout d'abord, félicitations aux organisateurs pour l'organisation, notamment pour les sessions du grand amphithéâtre avec la traduction simultanée pour les conférences en anglais (j'avoue ne pas avoir testé le casque audio), les interprètes en langue des signes ainsi que la vélotypie. Un petit bémol toutefois : il n'y avait pas assez de prises de courant pour que les personnes présentes puissent recharger leur ordinateur !

    Quant aux conférences elles-mêmes, pas mal de choses orientées utilisabilité, design, accessibilité et HTML5. Bien que je n'aie pas eu le sentiment d'apprendre beaucoup de choses techniquement, en particulier sur HTML5 où le contenu des présentations se recoupait trop et n'apportait de mon point de vue pas grand chose de nouveau, les orateurs ont su animer et rendre vivante leur présentation. Je retiendrai en particulier trois présentations :

    • Let’s interface - how to make people as excited about tech as we are de Christian Heilmann que je résumerai (très) rapidement en disant : réutiliser les outils et les données qui sont disponibles, ne pas repartir de zéro et rajouter une petite couche qui offre une réelle valeur ajoutée, ce n'est pas forcément très compliqué. Parmi les exemples cités : http://isithackday.com/hacks/geo/addmap.html
    • Innover de 9 à 5 par Olivier Thereaux : ou comment créer des espaces d'échange pour faire émerger de nouvelles idées puis les transformer en projets. Au final, aucune solution concrète ou miracle évidemment, et il me semble que c'était un des buts ("pas de recette de cuisine"), mais je retiens que d'après son expérience, il faut des gens avec l'esprit hacker, entendre bidouilleur. Ensuite, toutes les idées qui émergent ne sont pas bonnes, toutes les bonnes idées n'aboutissent pas et si celui qui a l'idée n'est pas directement celui qui s'occupe de la concrétiser, il y a peu de chances que ça fonctionne. Enfin, il faut ne pas avoir les yeux plus gros que le ventre et tempérer ses envies en fonction du temps (ou moyens) que l'on pourra y accorder et y aller petit pas par petit pas.
    • HTML5 et ses amis par Paul Rouget : une très belle présentation avec des démonstrations HTML5 (version Firefox4) très bien choisies : utilisation des websockets pour diffuser les slides sur ordinateurs clients, utilisation de FileReader pour la prévisualisation d'images côté client et une belle démonstration des capacités WebGL !

    Je n'ai entendu que des retours positifs sur la macrographie de la page Web à laquelle je n'ai malheureusement pas assisté personnellement mais d'autres logilabiens y étaient. J'ai également noté l'absence du web sémantique, ou alors je n'étais pas dans le bon amphi. En tout cas, tout ça m'a remotivé pour jouer avec HTML5 dans cubicweb. J'ai d'ailleurs commencé à faire une démo websocket dans cubicweb, affaire à suvire...


  • AgileFrance 2010: retour d'expérience sur la gestion agile du projet Pylos

    2010/10/07

    J'ai présenté au printemps dernier à l'occasion de la conférence AgileFrance2010 un retour d'expérience sur la gestion agile du projet Pylos. Mon "client" m'a fait la gentillesse de participer à l'élaboration de cette présentation et de venir co-présenter.

    Après avoir longtemps tardé, voici le support de la présentation (le texte se trouve à la fin, avec les notes pour les orateurs). Bonne lecture.

    Merci à Christine, et aux organisateurs de la conférence.

    http://blog.xebia.fr/wp-content/uploads/2010/05/speaker-2010.png

  • MiniDebConf Paris 2010

    2010/09/09 by Arthur Lutz
    http://france.debian.net/debian-france.png

    Debian France organise le 30 et 31 octobre prochain une minidebconf à Paris. Le wiki de la conférence est en train de s'étoffer, et pour le moment c'est là qu'il faut s'inscrire. À Logilab nous sommes utilisateurs et contributeurs de Debian, c'est donc naturellement que nous allons essayer d'aller participer à cette conférence. Alexandre Fayolle, développeur Debian ira assister (entre autres) à la présentation de Carl Chenet sur l'état de Python dans Debian.


  • Une mise en place de l’eXtreme Programming - ce que j'en retiens

    2010/05/20 by Arthur Lutz
    http://rubyonrails.org/images/rails.png

    Je suis allé à la présentation de "Une mise en place de l’eXtreme Programming" présenté par Karine Sabatier dans le cadre d'Agile Nantes. On y a parlé plutôt Ruby on Rails que python, mais surtout de méthodes agiles et XP.

    Voici quelques points que j'ai retenu de cette présentation tout à fait pragmatique d'une mise en pratique des principes XP :

    • Le principe de "Convention over configuration" : préférer la convention (notamment pour la programmation) plutôt que la contrainte par la configuration. Dans Ruby On Rails, les conventions sont très fortes, pour faire une application on ne peut pas s'éloigner du modèle MVC : les modèles sont dans "model", les views sont dans "views" etc... À ce sujet, la conférencière a fait référence à deux types de designs que je ne connaissait pas : le DDD Domain-driven Design et Behavior Driven Development.
    • Utilisation de métaphores : trouver un langage commun avec le client mais aussi avec les utilisateurs
    • Application de déploiement ruby on rails : Capistrano, bien qu'à Logilab nous privilégions le déploiement par paquets et dépôts debian, en python on pourra jeter un coup d'œil à Fabric.
    http://retrospectiva.org/extensions/overview/images/product_backlog.png?1265550417
    • Leur projet XP utilisait le logiciel de gestion de projet Retrospectiva. Celui-ci ressemble sur bien des points à JPL (Jeux de Planification Logiciel) disponible sur le framework CubicWeb (http://www.cubicweb.org). Coté intégration continue : CruiseControl , en python nous privilégions apycot.
    • Ce projet a essayé l'utilisation de Selenium pour ces tests web. Le constat est le même que chez Logilab : la première fois que ca marche c'est utile et apporte une grande satisfaction, dans un deuxième temps ca reste très difficile à maintenir. Nous regardons à présent plutôt du coté de Windmill qui a été intégré à la version 3.9 de cubicweb.
    • Une mention a été fait d'une société fonctionnement uniquement en mode agile Pyxis.

  • Sprint CubicWeb chez Logilab - annonce de dernière minute

    2010/04/29 by Arthur Lutz

    Logilab est en ce moment en train d'acceuillir un sprint autour de la plateforme CubicWeb. L'objectif principal de ce sprint de 5 jours est d'améliorer l'usage de javascript et des css dans CubicWeb :

    http://www.logilab.org/image/28586?vid=download http://codesnip.net/wp-content/uploads/javascript.png
    • avoir une API javascript propre, testée et documentée
    • pouvoir facilement changer le style d'une application cubicweb
    • gestion de bundle pour javascript et CSS
    • une documentation sur les standards d'écriture des fichiers JS et CSS pour cubicweb

    Ce sprint aura lieu du jeudi 29 avril 2010 au 5 mai 2010 (weekend exlus - les bureaux seront fermés). Vous êtes les bienvenus pour contribuer, filer un coup de main, faire du pair programming... ou simplement rencontrer des développeurs cubicweb. Vous pouvez même venir une après-midi ou une seule journée. Pour ceux avec des portables, il y aura du réseau disponible pour être connecté.

    Adresse : 104 Boulevard Auguste-Blanqui, Paris. Sonnez à "Logilab".

    Métro : St Jacques or Corvisart (Glacière est la station la plus proche mais sera fermée à partir de lundi)

    Contact : http://www.logilab.fr/contact

    Dates : du 29/04/2010 au 30/04/2010 et du 03/05/2010 au 05/05/2010


  • L'intégration continue présenté par Agiles Nantes

    2010/03/18 by Arthur Lutz

    Hier, Logilab était à nouveau présent aux rencontres organisées par Agiles Nantes, il s'agissait d'une présentation très fournie sur l'intégration continue (présenté par la société Netapsys). Malheureusement, la principale technologie utilisée était Java dont nous ne sommes pas des grands fans, préférant python. Néanmoins cela donne une bonne idée des possibilités qu'offrent les outils autour du développement java, notamment en terme d'intégration continue (voir Maven, Hudson, Sonar, etc.).

    http://hudson-ci.org/images/butler.png

    On retrouve donc un certain nombre de similarités avec le monde python, notamment avec Artifactory qui reproduit en partie les fonctionnalités de pypi avec easy_install ou buildout ou apt-cacher-ng dans son coté proxy. A Logilab, nous privilégions l'utilisation de paquets debian pour distribuer nos logiciels, ce qui permet, notamment, de ne pas réinventer la roue pour chaque langage de programmation.

    Voici quelques une des notions avancées lors de la présentation qui nous semblent intéressantes sur l'intégration continue :

    • celle-ci permet de mettre en place des environnements de test mis à disposition du client tout le long du projet.
    • cette notion de prototype utilisable en continu doit être présente le plus tôt possible dans un projet.
    • idéalement, un serveur de déploiement/intégration doit être quasiment à l'identique de l'environnement client (utilisation de machines virtuelles)
    • l'intégration continue est souvent plus utilisées par les développeurs et les chefs de projets que par les clients. Mettre en place des rapports utiles au client requiert un soin particulier
    • pour une émulation collective, certaines notations des développeurs sont possible. Par exemple un plugin Hudson donne un point par build réussi, un point par test ajouté, moins dix points pour un build cassé.
    • la visualisation des données peut motiver les développeurs, l'outil Sonar semble être très complet et propose des visualisation assez léchées. A noter, des graphes sur la complexité du code, par classe, par méthode etc. Voir aussi la visualisation de l'arbre des dépendances des librairies avec Radiator.
    http://sonar.codehaus.org/wp-content/themes/sonar/images/dashboard.png

    J'y ai mentionné apycot et buildbot qui sont tous les deux des outils plutôt orientés python (mais pas seulement).

    Pour conclure, tout ça m'a fait penser au concept plus poussé de "Continuous Delivery - BlueGreenDelivery" développé par Martin Fowler, une lecture recommandée pour ceux qui ont déjà pris le pas de l'intégration continue.

    http://www.martinfowler.com/bliki/images/blueGreenDeployment/blue_green_deployments.png

  • On a fait un tour au Coding Dojo à Nantes

    2010/02/18 by Arthur Lutz

    L'association de promotion des méthodes Agiles sur Nantes et sa région [1] organisait hier soir un "Coding Dojo". C'est une session de codage en public avec des créneaux de 15 minutes par codeur (explication sur codingdojo.org). Le focus de la session était le TDD (Test Driven Developpement).

    http://farm3.static.flickr.com/2509/3947717979_34e5a68d3d_m.jpg

    Annonce de l'événement sur leur site : http://www.agilenantes.org/2010/01/25/coding-dojo-mercredi-17-fevrier-2010/

    Photo par yepyep sous licence creative commons


  • Pylint a besoin de vous

    2009/09/17

    Après plusieurs mois au point mort ou presque, Sylvain a pu hier soir publier des versions corrigeant un certain nombre de bogues dans pylint et astng ([1] et [2]).

    Il n'en demeure pas moins qu'à Logilab, nous manquons de temps pour faire baisser la pile de tickets ouverts dans le tracker de pylint. Si vous jetez un œuil dans l'onglet Tickets, vous y trouverez un grand nombre de bogues en souffrance et de fonctionalités indispensables (certaines peut-être un peu moins que d'autres...) Il est déjà possible de contribuer en utilisant mercurial pour fournir des patches, ou en signalant des bogues (aaaaaaaaaarg ! encore des tickets !) et certains s'y sont mis, qu'ils en soient remerciés.

    Maintenant, nous nous demandions ce que nous pourrions faire pour faire avance Pylint, et nos premières idées sont :

    • organiser un petit sprint de 3 jours environ
    • organiser des jours de "tuage de ticket", comme ça se pratique sur différents projets OSS

    Mais pour que ça soit utile, nous avons besoin de votre aide. Voici donc quelques questions :

    • est-ce que vous participeriez à un sprint à Logilab (à Paris, France), ce qui nous permettrait de nous rencontrer, de vous apprendre plein de choses sur le fonctionnement de Pylint et de travailler ensemble sur des tickets qui vous aideraient dans votre travail ?
    • si la France c'est trop loin, où est-ce que ça vous arrangerait ?
    • seriez-vous prêt à vous joindre à nous sur le serveur jabber de Logilab ou sur IRC, pour participer à une chasse au ticket (à une date à déterminer). Si oui, quel est votre degré de connaissance du fonctionnement interne de Pylint et astng ?

    Vous pouvez répondre en commentant sur ce blog (pensez à vous enregistrer en utilisant le lien en haut à droite sur cette page) ou en écrivant à sylvain.thenault@logilab.fr. Si nous avons suffisamment de réponses positives nous organiserons quelque chose.


  • Nous allons à PyConFr 2009

    2009/05/25 by Arthur Lutz

    Le 30 et 31 mai prochain (samedi et dimanche prochain) nous allons être présents à PyConFr édition 2009, nous sommes partenaire de l'évènement et allons y parler de CubicWeb. Pour être plus précis, Nicolas Chauvat y présentera "CubicWeb pour publier DBpedia et OpenLibrary". Il avait déjà évoqué ces sujets sur ce site : Fetching book descriptions and covers et DBpedia 3.2 released.

    Si vous comptez y aller, n'hésitez pas à venir nous dire bonjour.

    http://pycon.fr/images/logo_pyconfr_small.png

  • 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.


  • Venez nous rendre visite à Solution Linux 2009

    2009/03/31 by Arthur Lutz
    http://www.solutionslinux.fr/images/index_07.jpg

    Nous sommes dès ce matin, pendant 3 jours, présents au salon Solutions Linux 2009 au stand du pôle de compétition System@tic dont nous faisons parti. C'est le stand B4/B8, assez prêt de l'entrée sur la gauche (détails).

    Nous allons présenter CubicWeb à plusieurs reprises sur le stand, ainsi que lors des conférences sur le Web2 ce mardi 31 mars de 14h à 17h30 :

    • Adrien présentera "Simile Widgets, des composants de haut niveau pour IHM web"
    • Sylvain présentera "Cubic 3.0 - une plateforme pour les applications web sémantique"

    pour plus de détails consultez le programme.


  • Belier - le ssh par hops

    2009/02/17 by Arthur Lutz

    On vient de découvrir belier qui permet de se connecter facilement à des machines auquelles on doit accéder par des machines ssh intermédiaires. Ca peut s'avérer utile. En plus, c'est en python. En plus, il a fait des paquets debian... et en plus il mentionne pylint. Du coup il mérite mention ici.

    http://www.ohmytux.com/belier/images/schema_belier.png

  • Résumé de la rencontre francophone autour des forges du 21 janvier 2009

    2009/01/27

    Définition d'une forge

    Je vous propose tout d'abord une définition assez complète d'une forge logicielle.

    « Une forge ou plate-forme d'hébergement de projets logiciels est un ensemble réunissant les technologies du travail coopératif et du génie logiciel pour permettre le développement coordonné de logiciels en équipe. Les services de base d'une telle plate-forme sont axés sur le partage de fichiers (code source, données et exécutables) et l'animation du groupe. Ils permettent la rédaction et la programmation collaborative, et facilitent la communication dans le groupe grâce à des outils associés aux projets tels que des gestionnaires de listes de messagerie, des logiciels de suivi des tâches et de gestion des rapports d'anomalies. L'utilisation d'une plate-forme de ce type améliore la qualité des réalisations en accélérant les processus d'échange entre développeurs et les cycles de version des logiciels, tout en facilitant l'implication des utilisateurs dans la détection des erreurs ou la mise en lumière des fonctionnalités pertinentes des logiciels.»

    Tirée de http://overcrowded.anoptique.org/ForgesEtatArt (licence Art Libre, créateur initial Benoît Sibaud, diffusable sous LAL, CC By, CC By-SA et GFDL).

    Voir:

    Problèmes recensés

    image by http://flickr.com/photos/fastjack/ under creative commons

    Je liste ici quelques problèmes qui m'ont semblé émerger pendant les discussions de la journée.

    • forks nombreux du projet GForge avec peu de collaboration entre les projets
    • périmètre technique souvent imposé dans le débat; ce qui gêne la définition fonctionnelle d'une forge
    • forte hiérarchie des responsabilités avec un rôle 'développeur' limité au profit de celui du 'chef de projet'
    • très orienté web avec une stratégie d'intégration de produits tiers; d'où une situation délicate pour l'homogénéité des solutions à cause des limitations du protocole HTTP
    • la méthodologie de conception des logiciels n'est pas évoquée dans le choix d'une solution (et pas d'approche Agile en général).

    Présentations

    ALM, cycle de vie des logiciels et poste client

    Voir:

    http://gforge.org/themes/gforgegroup/images/logo.jpg
    Projet NovaForge

    Forge très aboutie où une approche MDA a été mise en oeuvre pour la génération de cas de tests à partir des cas d'utilisation décrits en UML.

    Intégration continue

    Plusieurs outils ont été nommés. J'ai placé la liste sur la page du wiki dédiée.

    Interopérabilité sémantique

    Projet xfmigration

    Ce projet vise à migrer le contenu d'une forge (BerliOS) vers GForge sans passer par le backend SGBD. L'idée est alors d'utiliser différentes ontologies pour 'mapper' les concepts des 2 forges.

    Cross-Forge Migration Tool is a concept for facilitating the migration process of project metadata between forge platforms. It uses SWRL rules for mapping and OWL-S standard for exporting mapping results.

    Voir:

    Projet HELIOS

    L'exposé présentait un cas d'utilisation du web sémantique pour la recherche et le tri de rapport d'anomalies sur des forges séparées. L'exemple utilisé a été de pouvoir rapatrier; puis sélectionner des tickets relatifs au projet Konqueror à travers le bugzilla de Debian et celui du projet lui-même. Il est ainsi possible de détecter certains doublons ou incohérences de versions.

    http://www.cubicweb.org/index-cubicweb.png
    Projet CubicWeb forge

    J'ai pu présenter le framework CubicWeb et son architecture de composants. La présentation n'étant pas prévue initialement mais j'ai pû faire une démonstration à partir de la forge publique de Logilab.

    À partir d'un schéma enrichi des composants installés, il est possible de faire des requêtes RQL (similaire à SPARQL) sur des entités et des sources distantes (Base de données, LDAP, subversion, ...). Logilab travaille aujourd'hui à l'ajout d'ontologies dans la manipulation de ce schéma.

    Remerciements

    Je remercie les organisateurs de cette rencontre édition 2009 ainsi que l'ensemble des intervenants propices à l'échange de points de vue.


  • Rencontre francophone autour des forges

    2009/01/19
    http://farm1.static.flickr.com/25/61448490_5f9a023307_m.jpg

    Logilab sera présent le Mercredi 21 janvier à la rencontre francophone autour des forges. Les présentations et les discussions porteront sur :

    • échange de données entre forges, interopérabilité
    • définition d’un modèle d’intégration ouvert
    • recherche multi-forges
    • gestion des permissions et partage d’identités
    • interaction entre la forge et le poste client

    Logilab espère ainsi bénéficier de l'expérience de chacun et des pistes d'évolutions pour, à terme, les intégrer dans son projet de forge basé sur CubicWeb.

    Toutes les informations de l'événement sont disponibles ici.

    photo par StormyDog sous licence Creative Commons.


  • 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).


  • Semantic Roundup - infos glanées au NextMediaCamp

    2008/11/12 by Arthur Lutz
    http://barcamp.org/f/NMC.PNG

    Par manque de temps voici les infos en brut glanées jeudi soir dernier au NextMediaBarCamp :

    Un BarCamp c'est assez rigolo, un peu trop de jeune cadres dynamiques en cravate à mon goût, mais bon. Parmi les trois mini-conférences auxquelles j'ai participé, il y avait une sur le web sémantique. Animée en partie par Fabrice Epelboin qui écrit pour la version française de ReadWriteWeb, j'ai appris des choses. Pour résumer ce que j'y ai compris : le web sémantique il y a deux approches :

    1. soit on pompe le contenu existant et on le transforme en contenu lisible par les machines avec des algorithmes de la mort, comme opencalais le fait (top-down)
    2. soit on écrit nous même en web sémantique avec des microformats ensuite les machines liront de plus en plus le web (bottom-up)
    http://microformats.org/wordpress/wp-content/themes/microformats/img/logo.gif

    Dans le deuxième cas la difficulté est de faciliter la tache des rédacteurs du web pour qu'ils puissent facilement publier du contenu en web sémantique. Pour cela ces outils sont mentionnés : Zemanta, Glue (de la société AdaptiveBlue).

    Tout ça m'a fait penser au fait que si CubicWeb publie déjà en microformats, il lui manque une interface d'édition à la hauteur des enjeux. Par exemple lorsque l'on tape un article et que l'application a les coordonnées d'une personne metionnée, il fait automagiquement une relation à cet élément. A creuser...

    Sinon sur les autres confs et le futur des médias, selon les personnes présentes, c'est assez glauque : des medias publicitaires, custom-made pour le bonheur de l'individu, où l'on met des sous dans les agrégateurs de contenu plutôt sur des journalistes de terrain. Pour ceux que ça intéresse, j'ai aussi découvert lors de ce BarCamp un petit film "rigolo" qui traite ce sujet préoccupant.


  • Windows, fichiers ouverts et tests unitaires

    2008/07/22

    Un problème rencontré hier : un test unitaire plante sous Windows, après avoir créé un objet qui garde des fichiers ouverts. le tearDown du test est appelé, mais il plante car Windows refuse de supprimer des fichiers ouverts, et le framework de test garde une référence sur la fonction de test pour qu'on puisse examiner la pile d'appels. Sous Linux, pas de problème (on a le droit du supprimer du disque un fichier ouvert, et donc pas de soucis dans le teardown).

    Quelques pistes pour contourner le problème:

    1. mettre le test dans un try...finally avec un del sur l'objet qui garde les fichiers ouverts dans le finally. Inconvénient : quand le test ne passe pas, pdb ne permet plus de voir grand chose
    2. au lieu de nettoyer dans le tearDown, nettoyer plus tard dans un atexit par exemple. Il faut voir comment ça se passe si plusieurs tests veulent écrire dans les mêmes fichiers (je pense qu'il faudrait un répertoire temporaire par test, si on veut pouvoir avoir plusieurs tests qui foirent et examiner leurs données, mais il faut tester pour être sûr)
    3. coller un try...except dans le tearDown autour de la suppression de chaque fichier, et mettre les fichiers qui posent problème dans une liste qui sera traitée à la sortie du programme (avec atexit par exemple).

    Ça ressemble à du bricolage, mais on a un comportement de windows sur lequel on n'a pas de contrôle (même avec des privilèges Administrateur ou System, on ne peut pas contourner cette impossibilité de supprimer un fichier ouvert, à ma connaissance).

    Une autre approche, nettement plus lourde, serait de virtualiser la création de fichiers pour travailler en mémoire (au minimum surcharger os.mkdir et le builtin open, voire dans le cas qui nous intéresse les modules qui travaillent avec des fichiers zip). Il y a peut-être des choses comme ça en circulation. Poser la question sur la liste TIP apportera peut-être des réponses (une rapide recherche dans les archives n'a rien donné).

    Voir aussi ces enfilades de mars 2004 et novembre 2004 sur comp.lang.python.


  • SciLab passe en logiciel libre

    2008/06/16 by Arthur Lutz
    http://www.scilab.org/images/homepage/scilab_logo.png

    Bienvenue à SciLab version 5.0 dans le monde du logiciel libre. SciLab 5.0, plateforme open source de calcul scientifique sous licence CeCill, est une alternative crédible et maintenant reconnue comme telle à Matlab. Pour assurer le développement pérenne de Scilab, le consortium Scilab rejoint DIGITEO, parc de recherche d'envergure mondiale dans le domaine des sciences et technologies de l'information en Île-de-France.


  • Nouvelle version de LAX - Logilab Appengine eXtension

    2008/06/09 by Arthur Lutz
    http://code.google.com/appengine/images/appengine_lowres.jpg

    La version 0.3.0 de LAX est sortie aujourd'hui voir : http://lax.logilab.org/

    Il suffit de 10 petites minutes pour avoir une application qui tourne, suivez le guide :

    Mise à jour: LAX est maintenant inclus dans CubicWeb.


  • Présentation PyCON FR 2008 - Assurance qualité

    2008/05/27
    Photo sous licence creative commons `By-Nc-Nd`

    Une présentation sur l'assurance-qualité a été présentée le 17 mai 2008 pour les journées Python organisées par l'Association Francophone Python (AFPy).

    Le but visé est de décrire quelques notions et pratiques simples pour améliorer la lisibilité et la maintenabilité de votre code python.

    Quelques outils standards de python sont décrits en première partie; pour finir par une revue de projets plus ambitieux mais indispensables pour la création de code de qualité.

    Photo sous licence creative commons By-Nc-Nd par : yota

    Pour accéder au diaporama :

    http://fr.pycon.org/presentations_2008/julien-jehannet-assurance-qualite/slides.html


  • Présentation de Gendb à PyconFR

    2008/05/27 by Andre Espaze

    Ma présentation de 30 minutes est disponible à l'adresse suivante :

    http://fr.pycon.org/presentations_2008/andre-espaze-recherche-de-gene.pdf
    http://www.logilab.org/image/5136?vid=download

    La journée s'est bien passée, j'ai eu quelques questions. Un chercheur en génétique a demandé si le projet serait continué sur la recherche des peptides (car ce sont les gènes qui codent les peptides d'après ce que j'ai compris). J'ai transféré cette demande à Eric Eveno, je n'ai pas de réponse pour l'instant. Normalement, la vidéo devrait être disponible sur :

    http://fr.pycon.org/

    Vous pouvez me contactez si vous avez des questions : andre.espaze@logilab.fr


  • Profiter pleinement des CPUs avec Zope/Zeo/Debian

    2008/05/27 by Arthur Lutz

    Voici vite fait comment on profite du quad-core bi-proc multicoeurs avec zope/zeo/pound ... le tout en commandes debian.

    Inspiré de : http://plone.org/documentation/how-to/simple-zope-clustering-with-squid-and-pound

    http://plone.org/documentation/tutorial/introduction-to-the-zodb/zeo%20diagram.png
    • apt-get -uVf install plone-site pound

    • dzhandle -z 2.10 make-zeoinstance sgel_zeo

    • dzhandle -z 2.10 make-instance sgel2 --zeo-server=localhost:8100 -m all

    • dzhandle -z 2.10 make-instance sgel3 --zeo-server=localhost:8100 -m all

    • dzhandle -z 2.10 make-instance sgel1 --zeo-server=localhost:8100 -m all

    • dzhandle -z 2.10 make-instance sgel4 --zeo-server=localhost:8100 -m all

    • modifiez les ports de chaque instance (par exemple 9673, 9674, 9675, 9676)

    • vim ~/zope/instances/sgel*/etc/zope.conf

    • dzhandle add-product sgel1 CMFPlone

    • dzhandle add-product sgel2 CMFPlone

    • dzhandle add-product sgel3 CMFPlone

    • dzhandle add-product sgel4 CMFPlone

    • dzhandle zeoctl sgel_zeo start

    • dzhandle zopectl sgel1 start

    • dzhandle zopectl sgel2 start

    • dzhandle zopectl sgel3 start

    • dzhandle zopectl sgel4 start

    • vim /etc/pound/pound.cfg pour remplacer

      BackEnd
              Address 127.0.0.1
              Port    8080
      End
      

      par

      Service
              BackEnd
                      Address 127.0.0.1
                      Port    9673
              End
              BackEnd
                      Address 127.0.0.1
                      Port    9674
              End
              BackEnd
                      Address 127.0.0.1
                      Port    9675
              End
              BackEnd
                      Address 127.0.0.1
                      Port    9676
              End
      End
      
    • /etc/init.d/pound restart

    • tapez sur http://localhost:8080

    • ajoutez un site plone

    pour tester, lancez htop pour voir l'activité et regardez la différence entre :

    • apt-get -uVf install apache2-utils
    • /usr/sbin/ab -n 100 -c 100 localhost:8080/plone

    et

    • /usr/sbin/ab -n 100 -c 100 localhost:9673/plone

    nice!


  • Reinteract: un outil intéressant pour faire du numpy/scipy

    2008/05/27 by Arthur Lutz

    Il existe un outil, Reinteract, qui permet d'avoir une sorte de d'éditeur/shell Python, où l'on peut aisément modifier et réinterpreter une ligne de code.

    Sachant qu'il sait aussi afficher des plots, etc, il est possible de s'en servir avantageusement pour faire des sessions Matlab-like.

    Je pense donc que c'est un outil à présenter à nos chers apprenants qui sont intéressés par le couple python/numpy comme substitut à Matlab ©®.

    Ex:

    http://fishsoup.net/software/reinteract/reinteract-demo.png

    écrit par David Douard


  • Petit raccourci pratique avec ion3

    2008/05/27 by Arthur Lutz

    Un petit raccourci pratique pour ion3, qui permet, sur la combinaison de touches de son choix, de prendre le texte actuellement sélectionné (surligné) dans sa session X11, et, en fonction de son contenu :

    • d'ouvrir un onglet Firefox avec l'url sélectionnée,
    • d'ouvrir un xpdf si c'est une URL de fichier PDF,
    • lancer OpenOffice.org si c'est un fichier OOo,
    • ouvrir le fichier dans emacs si c'est un .py, .po, etc.
    • etc.

    Pour cela, il faut le script magique ci-dessous, et configurer ion pour appeler ce script sur la bonne combinaison de touches. Par ex. ajouter dans votre ~/.ion3/cfg_ion.lua les lignes

    defbindings("WMPlex.toplevel", {
      bdoc("Automagically view the selected string"),
      kpress(META.."F7",
             "ioncore.exec_on(_, '/home/user/bin/view')"),
    })
    

    Ici, j'ai mappé "Meta+F7", et le script est /home/user/bin/view

    #!/usr/bin/env python
    
    from mimetypes import guess_type
    import sys
    from os.path import abspath
    from os import system, popen
    
    import re
    RGX = re.compile
    
    EMACS = 'emacsclient --no-wait %(uri)s'
    EMACS_WITH_LINE = 'emacsclient --no-wait +%(lineno)s %(uri)s'
    FIREFOX = 'firefox -remote "openURL(%(uri)s, new-tab)"'
    WGET = 'cd /home/adim/tmp && wget %(uri)s & '
    
    commands = [
        ('text/html', FIREFOX),
        ('application/xml', EMACS),
        ('text', EMACS),
        ('image', 'display %(uri)s &'),
        ('application/pdf', 'xpdf %(uri)s &'),
        ('application/postcript', 'gv %(uri)s &'),
        ('application/vnd.sun.xml', 'ooffice %(uri)s &'), # matches writer, impress, etc.
        ('application/vnd.oasis.opendocument', 'ooffice %(uri)s &'),
        ('application/msword', 'ooffice %(uri)s &'),
        ('application/vnd.ms-', 'ooffice %(uri)s &'),
        ]
    
    patterns = [
        (RGX(r'https?://.*?(zip|gz|pdf|ods|doc|odt|ppt|sxw|sxi)$'), WGET),
        (RGX(r'.*(?P<uri>https?://[^ ()]*)( .*)?'), FIREFOX),
        (RGX('.*?\.conf$'), EMACS),
        (RGX('.*?\.po$'), EMACS),
        (RGX('.*?\.xslt$'), EMACS),
        (RGX('.*?\.pot$'), EMACS),
        (RGX(r'\s*F?i?l?e? ?"?(?P<uri>.*?\.py)", line (?P<lineno>\d+)[a-zA-Z_:-]*'), EMACS_WITH_LINE),
        (RGX('.*?(readme|changelog|depends|manifest|makefile)(\.in|\.gz|\.bz2)?$', re.I), EMACS),
        # others might come here ...
        ]
    
    def find_command(selection):
        for rgx, cmd in patterns:
            m = rgx.match(selection)
            if m:
                args = m.groupdict() or {'uri' : selection}
                return cmd, args
        mimetype, encoding = guess_type(selection)
        # XXX: encodings like zip, or gz could be handled
        if mimetype is not None:
            selection = abspath(selection)
            for registered_type, cmd in commands:
                if mimetype.startswith(registered_type):
                    return cmd, {'uri' : selection}
        raise ValueError('nothing matched')
    
    if len(sys.argv)>1:
        selected = ' '.join(sys.argv[1:])
    else:
        selected = popen('xclip -o').read()
    
    if selected:
        try:
            cmd, args = find_command(selected)
        except ValueError:
            # system('wmiijabber error viewing %s' % ' '.join(sys.argv[1:]))
            # XXX print a message in wmii status bar ?
            pass
        else:
            #print "yooo =>", repr(cmd), repr(args)
            system(cmd % args)
    

    Pour que cela fonctionne, il ne faut pas oublier d'installer xclip (sous debian, apt-get install xclip).

    -- écrit par David Douard sur un script de Adrien diMascio


  • Petites astuces de vim

    2008/05/27 by Arthur Lutz

    J'ai découvert vim-addons (qui est apparu dans debian récement) et ce petit outil permet de faire d'etendre les fonctionnalités de vim assez facilement. Voici une utilisation parmi tant d'autres :

    mode gnupg

    pour installer le mode gnupg faites

    vim-addons install gnupg
    

    Ensuite vim pourra ouvrir directement des fichiers encryptés et les réncrypter lorsque vous sauvez. Donc simplement

    vim mot-de-passe-envoyé-par-client.gpg
    

    Voilà, le tour est joué.

    J'avoue que je reste avec emacs pour le code, mais ce genre de petit raccourcis est bien pratique.


back to pagination (10 results)