back to pagination (10 results)

Blog entries

  • Au revoir Logilab 👋

    2021/12/16 by Arthur Lutz

    Après 17 ans à Logilab, je pars vers de nouveaux horizons... petite rétrospective en chiffres.

    À celles et ceux que j'ai eu le plaisir de croiser professionnellement,  j’espère vous recroiser dans le futur, sur du logiciel libre ou d'autres réseaux...

  • Typing Mercurial with pytype

    2019/11/14 by Denis Laxalde

    Following the recent introduction of Python type annotations (aka "type hints") in Mercurial (see, e.g. this changeset by Augie Fackler), I've been playing a bit with this and pytype.

    pytype is a static type analyzer for Python code. It compares with the more popular mypy but I don't have enough perspective to make a meaningful comparison at the moment. In this post, I'll illustrate how I worked with pytype to gradually add type hints in a Mercurial module and while doing so, fix bugs!

    The module I focused on is mercurial.mail, which contains mail utilities and that I know quite well. Other modules are also being worked on, this one is a good starting point because it has a limited number of "internal" dependencies, which both makes it faster to iterate with pytype and reduces side effects of other modules not being correctly typed already.

    shell $ pytype mercurial/ Computing dependencies Analyzing 1 sources with 36 local dependencies ninja: Entering directory `.pytype' [19/19] check mercurial.mail Success: no errors found

    The good news is that the module apparently already type-checks. Let's go deeper and merge the type annotations generated by pytype:

    $ merge-pyi -i mercurial/ out/mercurial/mail.pyi

    (In practice, we'd use --as-comments option to write type hints as comments, so that the module is still usable on Python 2.)

    Now we have all declarations annotated with types. Typically, we'd get many things like:

    sourceCode def codec2iana(cs) -> Any: cs = pycompat.sysbytes(email.charset.Charset(cs).input_charset.lower()) # "latin1" normalizes to "iso8859-1", standard calls for "iso-8859-1" if cs.startswith(b"iso") and not cs.startswith(b"iso-"): return b"iso-" + cs[3:] return cs

    The function signature has been annotated with Any (omitted for parameters, explicit for return value). This somehow means that type inference failed to find the type of that function. As it's (quite) obvious, let's change that into:

    sourceCode def codec2iana(cs: bytes) -> bytes: ...

    And re-run pytype:

    $ pytype mercurial/
    Computing dependencies
    Analyzing 1 sources with 36 local dependencies
    ninja: Entering directory `.pytype'
    [1/1] check mercurial.mail
    FAILED: .pytype/pyi/mercurial/mail.pyi 
    pytype-single --imports_info .pytype/imports/mercurial.mail.imports --module-name mercurial.mail -V 3.7 -o .pytype/pyi/mercurial/mail.pyi --analyze-annotated --nofail --quick mercurial/
    File "mercurial/", line 253, in codec2iana: Function Charset.__init__ was called with the wrong arguments [wrong-arg-types]
      Expected: (self, input_charset: str = ...)
      Actually passed: (self, input_charset: bytes)
    For more details, see
    ninja: build stopped: subcommand failed.

    Interesting! email.charset.Charset is apparently instantiated with the wrong argument type. While it's not exactly a bug, because Python will handle bytes instead of str well in general, we can again change the signature (and code) to:

    sourceCode def codec2iana(cs: str) -> str: cs = email.charset.Charset(cs).input_charset.lower() # "latin1" normalizes to "iso8859-1", standard calls for "iso-8859-1" if cs.startswith("iso") and not cs.startswith("iso-"): return "iso-" + cs[3:] return cs

    Obviously, this involves a larger refactoring in client code of this simple function, see respective changeset for details.

    Another example is this function:

    sourceCode def _encode(ui, s, charsets) -> Any: '''Returns (converted) string, charset tuple. Finds out best charset by cycling through sendcharsets in descending order. Tries both encoding and fallbackencoding for input. Only as last resort send as is in fake ascii. Caveat: Do not use for mail parts containing patches!''' sendcharsets = charsets or _charsets(ui) if not isinstance(s, bytes): # We have unicode data, which we need to try and encode to # some reasonable-ish encoding. Try the encodings the user # wants, and fall back to garbage-in-ascii. for ocs in sendcharsets: try: return s.encode(pycompat.sysstr(ocs)), ocs except UnicodeEncodeError: pass except LookupError: ui.warn(_(b'ignoring invalid sendcharset: %s\n') % ocs) else: # Everything failed, ascii-armor what we've got and send it. return s.encode('ascii', 'backslashreplace') # We have a bytes of unknown encoding. We'll try and guess a valid # encoding, falling back to pretending we had ascii even though we # know that's wrong. try: s.decode('ascii') except UnicodeDecodeError: for ics in (encoding.encoding, encoding.fallbackencoding): ics = pycompat.sysstr(ics) try: u = s.decode(ics) except UnicodeDecodeError: continue for ocs in sendcharsets: try: return u.encode(pycompat.sysstr(ocs)), ocs except UnicodeEncodeError: pass except LookupError: ui.warn(_(b'ignoring invalid sendcharset: %s\n') % ocs) # if ascii, or all conversion attempts fail, send (broken) ascii return s, b'us-ascii'

    It quite clear from the return value (last line) that we can change its type signature to:

    sourceCode def _encode(ui, s:Union[bytes, str], charsets: List[bytes]) -> Tuple[bytes, bytes] ...

    And re-run pytype:

    $ pytype mercurial/
    Computing dependencies
    Analyzing 1 sources with 36 local dependencies
    ninja: Entering directory `.pytype'
    [1/1] check mercurial.mail
    FAILED: .pytype/pyi/mercurial/mail.pyi 
    pytype-single --imports_info .pytype/imports/mercurial.mail.imports --module-name mercurial.mail -V 3.7 -o .pytype/pyi/mercurial/mail.pyi --analyze-annotated --nofail --quick mercurial/
    File "mercurial/", line 342, in _encode: bad option in return type [bad-return-type]
      Expected: Tuple[bytes, bytes]
      Actually returned: bytes
    For more details, see
    ninja: build stopped: subcommand failed.

    That's a real bug. Line 371 contains return s.encode('ascii', 'backslashreplace') in the middle of the function. We indeed return a bytes value instead of a Tuple[bytes, bytes] as elsewhere in the function. The following changes fixes the bug:

    sourceCode diff --git a/mercurial/ b/mercurial/ --- a/mercurial/ +++ b/mercurial/ @@ -339,7 +339,7 @@ def _encode(ui, s, charsets) -> Any: ui.warn(_(b'ignoring invalid sendcharset: %s\n') % ocs) else: # Everything failed, ascii-armor what we've got and send it. - return s.encode('ascii', 'backslashreplace') + return s.encode('ascii', 'backslashreplace'), b'us-ascii' # We have a bytes of unknown encoding. We'll try and guess a valid # encoding, falling back to pretending we had ascii even though we # know that's wrong.

    Steps by steps, by replacing Any with real types, adjusting "wrong" types like in the first example and fixing bugs, we finally get the whole module (almost) completely annotated.

  • Meetup Cloud Native Computing Nantes - Juin 2019 - Linkdump

    2019/06/20 by Arthur Lutz

    Hier, je suis allé au Meetup Cloud Native Computing Nantes sur KubeCon et la sécurité avec Kubernetes.

    Gaëlle Acas et Eric Briand ont présenté un retour sur la KubeCon Europe 2019.

    Alexandre Roman a présenté "La sécurité avec Kubernetes et les conteneurs Docker".

    Beaucoup de technologies ont été mentionnées ou discutées. À défaut de faire un résumé de ce qui s'y est dit, voici quelque liens collecté pendant le meetup :

    Merci au Meetup Cloud Native Computing Nantes, au VMware User Group, à Dell pour le sponsoring.

  • Mercurial conference in Paris: May 28th, 2019

    2019/05/03 by Marla Da Silva

    Mercurial Paris conference will take place on May 28th at Mozilla's headquarters, in Paris.

    Mercurial is a free distributed Source Control Management system. It offers an intuitive interface to efficiently handle projects of any size. With its powerful extension system, Mercurial can easily adapt to any environment.

    This first edition targets organizations that are currently using Mercurial or considering switching from another Version Control System, such as Subversion.

    Attending the conference will allow users to share ideas and version control experiences in different industries and at a different scale. It is a great opportunity to connect with Mercurial core developers and get updates about modern workflow and features.

    You are welcome to register here and be part of this first edition with us!

    Mercurial conference is co-organized by Logilab, Octobus & Rhode-Code.

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

    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.

  • Mercurial mini-sprint: from April 4th to 7th in Paris

    2019/03/19 by Marla Da Silva

    Logilab co-organizes with Octobus, a mini-sprint Mercurial to be held from Thursday 4 to Sunday 7 April in Paris.

    Logilab will host mercurial mini-sprint in its Paris premises on Thursday 4 and Friday 5 April. Octobus will be communicating very soon the place chosen to sprint during the weekend.

    To participate to mercurial mini-sprint, please complete the survey by informing your name and which days you will be joining us.

    Some of the developers working on mercurial or associated tooling plan to focus on improving the workflow and tool and documentation used for online collaboration through Mercurial (Kalithea, RhodeCode, Heptapod, Phabricator, sh.rt, etc. You can also fill the pad below to indicate the themes that you want to tackle during this sprint:

    Let's code together!

  • 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 : Si ces technos vous intéressent, je vous encourage vivement à dérouler ce workshop.

    J'ai parcouru la liste des 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 :

    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.

  • Logilab trip report for FOSDEM 2019

    2019/02/13 by Nicolas Chauvat

    A very large conference

    This year I attended the FOSDEM in Brussels for the first time. I have been doing free software for more than 20 years, but for some reason, I had never been to FOSDEM. I was pleasantly surprised to see that it was much larger than I thought and that it gathered thousands of people. This is by far the largest free software event I have been to. My congratulations to the organizers and volunteers, since this must be a huge effort to pull off.

    My presentation about CubicWeb

    I went to FOSDEM to present Logilab's latest project, a reboot of CubicWeb to turn it into a web extension to browse the web of data. The recording of the talk, the slides and the video of the demo are online, I hope you enjoy them and get in touch with me if you are to comment or contribute.

    My highlights

    As usual, the "hallway track" was the most useful for me and there are more sets of slides I read than talks I could attend.

    I met with Bram, the author of redbaron and we had a long discussion about programming in different languages.

    I also met with Octobus. We discussed Heptapod, a project to add Mercurial support to Gitlab. Logilab would back such a project with money if it were to become usable and (please) move towards federation (with ActivityPub?) and user queries (with GraphQL?). We also discussed the so-called oxydation of Mercurial, which consists in rewriting some parts in Rust. After a quick search I saw that tools like PyO3 can help writing Python extensions in Rust.

    Some of the talks that interested me included:

    • Memex, that reuses the name of the very first hypertext system described in the litterature, and tries to implement a decentralized annotation system for the web. It reminded me of Web hypothesis and W3C's annotations recommendation which they say they will be compatible with.
    • GraphQL was presented both in GraphQL with Python and Testing GraphQL with Javascript. I have been following GraphQL about two years because it compares to the RQL language of CubicWeb. We have been testing it at Logilab with cubicweb-graphql.
    • Web Components are one of the options to develop user interfaces in the browser. I had a look at the Future of Web Components, which I relate to the work we are doing with the CubicWeb browser (see above) and the work the Virtual Assembly has been doing to implement Transiscope.
    • Pyodide, the scientific python stack compiled to Web Assembly, I try to compare it to using Jupyter notebooks.
    • Chat-over-IMAP another try to rule them all chat protocols. It is right that everyone has more than one email address, that email addresses are more and more used as logins in many web sites and that using these email addresses as instant-messaging / chat addresses would be nice. We will see if it takes off!

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

    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

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


    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.


    Voilà. Plein d'autres conférences méritent d'être visionnées sur (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!

  • Experiment to safely refactor your code in Python

    2018/05/05 by Nicolas Chauvat

    "Will my refactoring break my code ?" is the question the developer asks himself because he is not sure the tests cover all the cases. He should wonder, because tests that cover all the cases would be costly to write, run and maintain. Hence, most of the time, small decisions are made day after day to test this and not that. After some time, you could consider that in a sense, the implementation has become the specification and the rest of the code expects it not to change.

    Enters Scientist, by GitHub, that inspired a Python port named Laboratory.

    Let us assume you want to add a cache to a function that reads data from a database. The function would be named read_from_db, it would take an int as parameter item_id and return a dict with attributes of the items and their values.

    You could experiment with the new version of this function like so:

    import laboratory
    def read_from_db_with_cache(item_id):
        data = {}
        # some implementation with a cache
        return data
    def read_from_db(item_id):
         data = {}
         #  fetch data from db
         return data

    When you run the above code, calling read_from_db returns its result as usual, but thanks to laboratory, a call to read_from_db_with_cache is made and its execution time and result are compared with the first one. These measurements are logged to a file or sent to your metrics solution for you to compare and study.

    In other words, things continue to work as usual as you keep the original function, but at the same time you experiment with its candidate replacement to make sure switching will not break or slow things down.

    I like the idea ! Thank you for Scientist and Laboratory that are both available under the MIT license.

  • Reduce docker image size with multi-stage builds

    2018/03/21 by Philippe Pepiot

    At logilab we use more and more docker both for test and production purposes.

    For a CubicWeb application I had to write a Dockerfile that does a pip install and compiles javascript code using npm.

    The first version of the Dockerfile was:

    FROM debian:stretch
    RUN apt-get update && apt-get -y install \
        wget gnupg ca-certificates apt-transport-https \
        python-pip python-all-dev libgecode-dev g++
    RUN echo "deb stretch main" > /etc/apt/sources.list.d/nodesource.list
    RUN wget -O - | apt-key add -
    RUN apt-get update && apt-get -y install nodejs
    COPY . /sources
    RUN pip install /sources
    RUN cd /sources/frontend && npm install && npm run build && \
        mv /sources/frontend/bundles /app/bundles/
    # ...

    The resulting image size was about 1.3GB which cause issues while uploading it to registries and with the required disk space on production servers.

    So I looked how to reduce this image size. What is important to know about Dockerfile is that each operation result in a new docker layer, so removing useless files at the end will not reduce the image size.

    The first change was to use debian:stretch-slim as base image instead of debian:stretch, this reduced the image size by 18MB.

    Also by default apt-get would pull a lot of extra optional packages which are "Suggestions" or "Recommends". We can simply disable it globally using:

    RUN echo 'APT::Install-Recommends "0";' >> /etc/apt/apt.conf && \
        echo 'APT::Install-Suggests "0";' >> /etc/apt/apt.conf

    This reduced the image size by 166MB.

    Then I looked at the content of the image and see a lot of space used in /root/.pip/cache. By default pip build and cache python packages (as wheels), this can be disabled by adding --no-cache to pip install calls. This reduced the image size by 26MB.

    In the image we also have a full nodejs build toolchain which is useless after the bundles are generated. The old workaround is to install nodejs, build files, remove useless build artifacts (node_modules) and uninstall nodejs in a single RUN operation, but this result in a ugly Dockerfile and will not be an optimal use of the layer cache. Instead we can setup a multi stage build

    The idea behind multi-stage builds is be able to build multiple images within a single Dockerfile (only the latest is tagged) and to copy files from one image to another within the same build using COPY --from= (also we can use a base image in the FROM clause).

    Let's extract the javascript building in a single image:

    FROM debian:stretch-slim as base
    RUN echo 'APT::Install-Recommends "0";' >> /etc/apt/apt.conf && \
        echo 'APT::Install-Suggests "0";' >> /etc/apt/apt.conf
    FROM base as node-builder
    RUN apt-get update && apt-get -y install \
        wget gnupg ca-certificates apt-transport-https \
    RUN echo "deb stretch main" > /etc/apt/sources.list.d/nodesource.list
    RUN wget -O - | apt-key add -
    RUN apt-get update && apt-get -y install nodejs
    COPY . /sources
    RUN cd /sources/frontend && npm install && npm run build
    FROM base
    RUN apt-get update && apt-get -y install python-pip python-all-dev libgecode-dev g++
    RUN pip install --no-cache /sources
    COPY --from=node-builder /sources/frontend/bundles /app/bundles

    This reduced the image size by 252MB

    The Gecode build toolchain is required to build rql with gecode extension (which is a lot faster that native python), my next idea was to build rql as a wheel inside a staging image, so the resulting image would only need the gecode library:

    FROM debian:stretch-slim as base
    RUN echo 'APT::Install-Recommends "0";' >> /etc/apt/apt.conf && \
        echo 'APT::Install-Suggests "0";' >> /etc/apt/apt.conf
    FROM base as node-builder
    RUN apt-get update && apt-get -y install \
        wget gnupg ca-certificates apt-transport-https \
    RUN echo "deb stretch main" > /etc/apt/sources.list.d/nodesource.list
    RUN wget -O - | apt-key add -
    RUN apt-get update && apt-get -y install nodejs
    COPY . /sources
    RUN cd /sources/frontend && npm install && npm run build
    FROM base as wheel-builder
    RUN apt-get update && apt-get -y install python-pip python-all-dev libgecode-dev g++ python-wheel
    RUN pip wheel --no-cache-dir --no-deps --wheel-dir /wheels rql
    FROM base
    RUN apt-get update && apt-get -y install python-pip
    COPY --from=wheel-builder /wheels /wheels
    RUN pip install --no-cache --find-links /wheels /sources
    # a test to be sure that rql is built with gecode extension
    RUN python -c 'import rql.rql_solve'
    COPY --from=node-builder /sources/frontend/bundles /app/bundles

    This reduced the image size by 297MB.

    So the final image size goes from 1.3GB to 300MB which is more suitable to use in a production environment.

    Unfortunately I didn't find a way to copy packages from a staging image, install it and remove the package in a single docker layer, a possible workaround is to use an intermediate http server.

    The next step could be to build a Debian package inside a staging image, so the build process would be separated from the Dockerfile and we could provide Debian packages along with the docker image.

    Another approach could be to use Alpine as base image instead of Debian.

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

    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 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 (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,
    • 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 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 et un démonstrateur temporaire ici.

    Yapuka continuer…

  • Mercurial Sprint 4.4

    2017/10/10 by Denis Laxalde

    In late September, I participated on behalf of Logilab to the Mercurial 4.4 sprint that held at Facebook Dublin. It was the opportunity to meet developers of the project, follow active topics and forthcoming plans for Mercurial. Here, I'm essentially summarizing the main points that held my attention.

    Amongst three days of sprint, the first two mostly dedicated to discussions and the last one to writing code. Overall, the organization was pretty smooth thanks to Facebook guys doing a fair amount of preparation. Amongst an attendance of 25 community members, some companies had a significant presence: noticeably Facebook had 10 employees and Google 5, the rest consisting of either unaffiliated people and single-person representing their affiliation. No woman, unfortunately, and a vast majority of people with English as a native or dominant usage language.

    The sprint started by with short talks presenting the state of the Mercurial project. Noticeably, in the state of the community talk, it was recalled that the project governance now holds on the steering committee while some things are still not completely formalized (in particular, the project does not have a code of conduct yet). Quite surprisingly, the committee made no explicit mention of the recurring tensions in the project which recently lead to a banishment of a major contributor.

    Facebook, Google, Mozilla and Unity then presented by turns the state of Mercurial usages in their organization. Both Facebook and Google have a significant set of tools around hg, most of them either aiming at making the user experience more smooth with respect to performance problems coming from their monorepos or towards GUI tools. Other than that, it's interesting to note most of these corporate users have now integrated evolve on the user side, either as is or with a convenience wrapper layer.

    After that, followed several "vision statements" presentations combined with breakout sessions. (Just presenting a partial selection.)

    The first statement was about streamlining the style of the code base: that one was fairly consensual as most people agreed upon the fact that something has to be done in this respect; it was finally decided (on the second day) to adopt a PEP-like process. Let's see how things evolve!

    Second, Boris Feld and I talked about the development of the evolve extension and the ongoing task about moving it into Mercurial core (slides). We talked about new usages and workflows around the changeset evolution concept and the topics concept. Despite the recent tensions on this technical topic in the community, we tried to feel positive and reaffirmed that the whole community has interests in moving evolve into core. On the same track, in another vision statement, Facebook presented their restack workflow (sort of evolve for "simple" cases) and suggested to push this into core: this is encouraging as it means that evolve-like workflows tend to get mainstream.


    Another interesting vision statement was about using Rust in Mercurial. Most people agreed that Mercurial would benefit from porting its native C code in Rust, essentially for security reasons and hopefully to gain a bit of performance and maintainability. More radical ideas were also proposed such as making the hg executable a Rust program (thus embedding a Python interpreter along with its standard library) or reimplementing commands in Rust (which would pose problems with respect to the Python extension system). Later on, Facebook presented mononoke, a promising Mercurial server implemented in Rust that is expected to scale better with respect to high committing rates.

    Back to a community subject, we discussed about code review and related tooling. It was first recalled that the project would benefit from more reviewers, including people without a committer status. Then the discussion essentially focused on the Phabricator experiment that started in July. Introduction of a web-based review tool in Mercurial was arguably a surprise for the community at large since many reviewers and long-time contributors have always expressed a clear preference over email-based review. This experiment is apparently meant to lower the contribution barrier so it's nice to see the project moving forward on this topic and attempt to favor diversity by contribution. On the other hand, the choice of Phabricator was quite controversial. From the beginning (see replies to the announcement email linked above), several people expressed concerns (about notifications notably) and some reviewers also complained about the increase of review load and loss of efficiency induced by the new system. A survey recently addressed to the whole community apparently (no official report yet at the time of this writing) confirms that most employees from Facebook or Google seem pretty happy with the experiment while other community members generally dislike it. Despite that, it was decided to keep the "experiment" going while trying to improve the notification system (better threading support, more diff context, subscription-based notification, etc.). That may work, but there's a risk of community split as non-corporate members might feel left aside. Overall, adopting a consensus-based decision model on such important aspects would be beneficial.

    Yet another interesting discussion took place around branching models. Noticeably, Facebook and Google people presented their recommended (internal) workflow respectively based on remotenames and local bookmarks while Pulkit Goyal presented the current state to the topics extension and associated workflows. Bridging the gap between all these approaches would be nice and it seems that a first step would be to agree upon the definition of a stack of changesets to define a current line of work. In particular, both the topics extension and the show command have their own definition, which should be aligned.

    (Comments on reddit.)

  • Better code archaeology with Mercurial

    2017/09/21 by Denis Laxalde

    For about a year, Logilab has been involved in Mercurial development in the framework of a Mozilla Open Source Support (MOSS) program. Mercurial is a foundational technology for Mozilla, as the VCS used for the development of Firefox. As the main protagonist of the program, I'd first like to mention this has been a very nice experience for me, both from the social and technical perspectives. I've learned a lot and hope to continue working on this nice piece of software.

    The general objective of the program was to improve "code archaeology" workflows, especially when using hgweb (the web UI for Mercurial). Outcomes of program spread from versions 4.1 to 4.4 of Mercurial and I'm going to present the main (new) features in this post.

    Better navigation in "blame/annotate" view (hgweb)

    The first feature concerns the "annotate" view in hgweb; the idea was to improve navigation along "blamed" revisions, a process that is often tedious and involves a lot of clicks in the web UI (not easier from the CLI, for that matter). Basically, we added an hover box on the left side of file content displaying more context on blamed revision along with a couple of links to make navigation easier (links to parent changesets, diff and changeset views). See below for an example about mercurial.error module (to try it at

    The hover box in annotate view in hgweb.


    While this wasn't exactly in the initial scope of the program, the most interesting result of my work is arguably the introduction of the "followlines" feature set. The idea is to build upon the log command instead of annotate to make it easier to follow changes across revisions and the new thing is to make this possible by filtering changes only affecting a block of lines in a particular file.

    The first component introduced a revset, named followlines, which accepts at least two arguments a file path and a line range written as fromline:toline (following Python slice syntax). For instance, say we are interested the history of LookupError class in mercurial/ module which, at tag 4.3, lives between line 43 and 59, we'll use the revset as follows:

    $ hg log -r 'followlines(mercurial/, 43:59)'
    changeset:   7633:08cabecfa8a8
    user:        Matt Mackall <>
    date:        Sun Jan 11 22:48:28 2009 -0600
    summary:     errors: move revlog errors
    changeset:   24038:10d02cd18604
    user:        Martin von Zweigbergk <>
    date:        Wed Feb 04 13:57:35 2015 -0800
    summary:     error: store filename and message on LookupError for later
    changeset:   24137:dcfdfd63bde4
    user:        Siddharth Agarwal <>
    date:        Wed Feb 18 16:45:16 2015 -0800
    summary:     error.LookupError: rename 'message' property to something
    changeset:   25945:147bd9e238a1
    user:        Gregory Szorc <>
    date:        Sat Aug 08 19:09:09 2015 -0700
    summary:     error: use absolute_import
    changeset:   34016:6df193b5c437
    user:        Yuya Nishihara <>
    date:        Thu Jun 01 22:43:24 2017 +0900
    summary:     py3: implement __bytes__() on most of our exception classes

    This only yielded changesets touching this class.

    This is not an exact science (because the algorithm works on diff hunks), but in many situations it gives interesting results way faster that with an iterative "annotate" process (in which one has to step from revision to revision and run annotate every times).

    The followlines() predicate accepts other arguments, in particular, descend which, in combination with the startrev, lets you walk the history of a block of lines in the descending direction of history. Below the detailed help (hg help revset.followlines) of this revset:

    $ hg help revsets.followlines
        "followlines(file, fromline:toline[, startrev=., descend=False])"
          Changesets modifying 'file' in line range ('fromline', 'toline').
          Line range corresponds to 'file' content at 'startrev' and should hence
          be consistent with file size. If startrev is not specified, working
          directory's parent is used.
          By default, ancestors of 'startrev' are returned. If 'descend' is True,
          descendants of 'startrev' are returned though renames are (currently)
          not followed in this direction.

    In hgweb

    The second milestone of the program was to port this followlines filtering feature into hgweb. This has been implemented as a line selection mechanism (using mouse) reachable from both the file and annotate views. There, you'll see a small green ± icon close to the line number. By clicking on this icon, you start the line selection process which can be completed by clicking on a similar icon on another line of the file.

    Starting a line selection for followlines in hgweb.

    After that, you'll see a box inviting you to follow the history of lines <selected range> , either in the ascending (older) or descending (newer) direction.

    Line selection completed for followlines in hgweb.

    Here clicking on the "newer" link, we get:

    Followlines result in hgweb.

    As you can notice, this gives a similar result as with the command line but it also displays the patch of each changeset. In these patch blocks, only the diff hunks affecting selected line range are displayed (sometimes with some extra context).

    What's next?

    At this point, the "followlines" feature is probably complete as far as hgweb is concerned. In the remainder of the MOSS program, I'd like to focus on a command-line interface producing a similar output as the one above in hgweb, i.e. filtering patches to only show followed lines. That would take the form of a --followlines/-L option to hg log command, e.g.:

    $ hg log -L mercurial/,43:59 -p

    That's something I'd like to tackle at the upcoming Mercurial 4.4 sprint in Dublin!

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


    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.


    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.

  • 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 . Matlo a commencé à migrer vers une solution SASS (monitoring as a service) chez (entreprise Toulousaine). La stack de bleemeo est décrite sur stackshare: L'agent de bleemeo est publié en logiciel libre et repose sur telegraf . Bleemeo semble utiliser MQTT-SSL pour remonter les métriques permettant ainsi un usage raisonnable des connexions réseau (cf diagramme

    Emeric / OasisWork

    Emeric de OasisWork nous a présenté leur utilisation de sensu 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 et Oasiswork a contribué à ces 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 Pour la visualisation l'interface web libre de sensu est utilisée : uchiwa.

    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à).

    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.


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


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


    En fin de meetup nous avons parlé des conférences devoxx publiés récemment et des contenus sur le monitoring et l'aggrégation de logs, notamment le projet cerebro de voyage-sncf :

  • A non-numeric Pandas example with Geonames

    2017/02/20 by Yann Voté

    The aim of this 2-parts blog post is to show some useful, yet not very complicated, features of the Pandas Python library that are not found in most (numeric oriented) tutorials.

    We will illustrate these techniques with Geonames data : extract useful data from the Geonames dump, transform it, and load it into another file. There is no numeric computation involved here, nor statictics. We will prove that pandas can be used in a wide range of cases beyond numerical analysis.

    While the first part was an introduction to Geonames data, this second part contains the real work with Pandas. Please read part 1 if you are not familiar with Geonames data.

    The project

    The goal is to read Geonames data, from allCountries.txt and alternateNames.txt files, combine them, and produce a new CSV file with the following columns:

    • gid, the Geonames id,
    • frname, French name when available,
    • gname, Geonames main name,
    • fclass, feature class,
    • fcode, feature code,
    • parent_gid, Geonames id of the parent location,
    • lat, latitude,
    • lng, longitude.

    Also we don't want to use too much RAM during the process. 1 GB is a maximum.

    You may think that this new CSV file is a low-level objective, not very interesting. But it can be a step into a larger process. For example one can build a local Geonames database that can then be used by tools like Elastic Search or Solr to provide easy searching and auto-completion in French.

    Another interesting feature is provided by the parent_gid column. One can use this column to build a tree of locations, or a SKOS thesaurus of concepts.

    The method

    Before diving into technical details, let us first look at the big picture, the overall process to achieve the aforementioned goal.

    Considering the wanted columns, we can see the following differences with allCountries.txt:

    • we are not interested in some original columns (population, elevation, ...),
    • the column frname is new and will come from alternateNames.txt, thanks to the Geonames id,
    • the column parent_gid is new too. We must derive this information from the adminX_code (X=1, 2, 3, 4) columns in allCountries.txt.

    This column deserves an example. Look at Arrondissement de toulouse.

    feature_code: ADM3, country_code: FR, admin1_code: 76, admin2_code: 31, admin3_code: 313

    To find its parent, we must look at a place with the following properties,

    feature_code: ADM2, country_code: FR, admin1_code: 76, admin2_code: 31

    and there is only one place with such properties, Geonames id 3,013,767, namely Département de la Haute-Garonne. Thus we must find a way to derive the Geonames id from the feature_code, country_code and adminX_code columns. Pandas will make this easy for us.

    Let's get to work. And of course, we must first import the Pandas library to make it available. We also import the csv module because we will need it to perform basic operations on CSV files.

    >>> import pandas as pd
    >>> import csv

    The French names step

    Loading file

    We begin by loading data from the alternateNames.txt file.

    And indeed, that's a big file. To save memory we won't load the whole file. Recall from previous part, that the alternateNames.txt file provides the following columns in order.

    alternateNameId   : the id of this alternate name, int
    geonameid         : geonameId referring to id in table 'geoname', int
    isolanguage       : iso 639 language code 2- or 3-characters; (...)
    alternate name    : alternate name or name variant, varchar(400)
    isPreferredName   : '1', if this alternate name is an official/preferred name
    isShortName       : '1', if this is a short name like 'California' for 'State of California'
    isColloquial      : '1', if this alternate name is a colloquial or slang term
    isHistoric        : '1', if this alternate name is historic and was used in the pastq

    For our purpose we are only interested in columns geonameid (so that we can find corresponding place in allCountries.txt file), isolanguage (so that we can keep only French names), alternate name (of course), and isPreferredName (because we want to keep preferred names when possible).

    Another way to save memory is to filter the file before loading it. Indeed, it's a better practice to load a smaller dataset (filter before loading) than to load a big one and then filter it after loading. It's important to keep those things in mind when you are working with large datasets. So in our case, it is cleaner (but slower) to prepare the CSV file before, keeping only French names.

    >>> # After restarting Python
    >>> with open('alternateNames.txt') as f:
    ...     reader = csv.reader(f, delimiter='\t', quoting=csv.QUOTE_NONE)
    ...     with open('frAltNames.txt', 'w') as g:
    ...         writer = csv.writer(g, delimiter='\t', quoting=csv.QUOTE_NONE,
    ...                             escapechar='\\')
    ...         for row in reader:
    ...             if row[2] == u'fr':
    ...                 writer.writerow(row)

    To load a CSV file, Pandas provides the read_csv function. It returns a dataframe populated with data from a CSV file.

    >>> with open('frAltNames.txt') as altf:
    ...     frnames = pd.read_csv(
    ...         altf, encoding='utf-8',
    ...         sep='\t', quoting=csv.QUOTE_NONE,
    ...         header=None, usecols=(1, 3, 4), index_col=0,
    ...         names=('gid', 'frname', 'pref'),
    ...         dtype={'gid': 'uint32', 'frname': str, 'pref': 'bool_'},
    ...         true_values=['1'], false_values=[u''], na_filter=False,
    ...         skipinitialspace=True, error_bad_lines=False
    ...     )

    The read_csv function is quite complex and it takes some time to use it rightly. In our cases, the first few parameters are self-explanatory: encoding for the file encoding, sep for the CSV separator, quoting for the quoting protocol (here there is none), and header for lines to be considered as label lines (here there is none).

    usecols tells pandas to load only the specified columns. Beware that indices start at 0, so column 1 is the second column in the file (geonameid in this case).

    index_col says to use one of the columns as a row index (instead of creating a new index from scratch). Note that the number for index_col is relative to usecols. In other words, 0 means the first column of usecols, not the first column of the file.

    names gives labels for columns (instead of using integers from 0). Hence we can extract the last column with frnames['pref'] (instead of frnames[3]). Please note, that this parameter is not compatible with headers=0 for example (in that case, the first line is used to label columns).

    The dtype parameter is interesting. It allows you to specify one type per column. When possible, prefer to use NumPy types to save memory (eg np.uint32, np.bool_).

    Since we want boolean values for the pref column, we can tell Pandas to convert '1' strings to True and empty strings ('') to False. That is the point of using parameters true_values and false_values.

    But, by default, Pandas detect empty strings and affect them np.nan (NaN means not a number). To prevent this behavior, setting na_filter to False will leave empty strings as empty strings. Thus, empty strings in the pref column will be converted to False (thanks to the false_values parameter and to the 'bool_' data type).

    Finally, skipinitialspace tells Pandas to left-strip strings to remove leading spaces. Without it, a line like a, b (commas-separated) would give values 'a' and ' b' (note leading space before b).

    And lastly, error_bad_lines make pandas ignore lines he cannot understand (eg. wrong number of columns). The default behavior is to raise an exception.

    There are many more parameters to this function, which is much more powerful than the simple reader object from the csv module. Please, refer to the documentation at for a full list of options. For example, the header parameter can accept a list of integers, like [1, 3, 4], saying that lines at position 1, 3 and 4 are label lines.

    <class 'pandas.core.frame.DataFrame'>
    Int64Index: 55684 entries, 18918 to 11441793
    Data columns (total 2 columns):
    frname     55684 non-null object
    pref       55684 non-null bool
    dtypes: bool(1), object(1)
    memory usage: 6.6 MB

    We can see here that our dataframe contains 55,684 entries and that it takes about 6.6 MB in memory.

    Let's look at entry number 3,013,767 for the Haute-Garonne department.

    >>> frnames.loc[3013767]
                                     frname    pref
    3013767  Département de la Haute-Garonne  False
    3013767                    Haute-Garonne   True

    Removing duplicated indices

    There is one last thing to do with the frnames dataframe: make its row indices uniques. Indeed, we can see from the previous example that there are two entries for the Haute-Garonne department. We need to keep only one, and, when possible, the preferred form (when the pref column is True).

    This is not always possible: we can see at the beginning of the dataframe (use the head method) that there is no preferred French name for Rwanda.

    >>> frnames.head()
                         frname   pref
    18918              Protaras   True
    49518  République du Rwanda  False
    49518                Rwanda  False
    50360       Woqooyi Galbeed  False
    51230              Togdheer  False

    In such a case, we will take one of the two lines at random. Maybe a clever rule to decide which one to keep would be useful (like involving other columns), but for the purpose of this tutorial it does not matter which one is kept.

    Back to our problem, how to make indices uniques ? Pandas provides the duplicated method on Index objects. This method returns a boolean NumPy 1d-array (a vector), the size of which is the number of entries. So, since our dataframe has 55,684 entries, the length of the returned vector is 55,684.

    >>> dups_idx = frnames.index.duplicated()
    >>> dups_idx
    array([False, False,  True, ..., False, False, False], dtype=bool)
    >>> len(dups_idx)

    The meaning is simple: when you encounter True, it means that the index at this position is a duplicate of a previously encountered index. For example, we can see that the third value in dups_idx is True. And indeed, the third line of frnames has an index (49,518) which is a duplicate of the second line.

    So duplicated is meant to mark as True duplicated indices and to keep only the first one (there is an optional parameter to change this: read the doc). How do we make sure that the first entry is the preferred entry ? Sorting the dataframe of course! We can sort a table by a column (or by a list of columns), using the sort_values method. We give ascending=False because True > False (that's a philosophical question!), and inplace=True to sort the dataframe in place, thus we do not create a copy (still thinking about memory usage).

    >>> frnames.sort_values('pref', ascending=False, inplace=True)
    >>> frnames.head()
                                   frname  pref
    18918                        Protaras  True
    8029850  Hôtel de ville de Copenhague  True
    8127417                        Kalmar  True
    8127361                     Sundsvall  True
    8127291                        Örebro  True
    >>> frnames.loc[3013767]
                                      frname   pref
    3013767                    Haute-Garonne   True
    3013767  Département de la Haute-Garonne  False

    Great! All preferred names are now first in the dataframe. We can then use the duplicated index method to filter out duplicated entries.

    >>> frnames = frnames[~(frnames.index.duplicated())]
    >>> frnames.loc[3013767]
    frname     Haute-Garonne
    pref                True
    Name: 3013767, dtype: object
    >>> frnames.loc[49518]
    frname     Rwanda
    pref        False
    Name: 49518, dtype: object
    <class 'pandas.core.frame.DataFrame'>
    Int64Index: 49047 entries, 18918 to 11441793
    Data columns (total 2 columns):
    frname     49047 non-null object
    pref       49047 non-null bool
    dtypes: bool(1), object(1)
    memory usage: 5.7 MB

    We end up with 49,047 French names. Notice the ~ in the filter expression ? That's because we want to keep the first entry for each duplicated index, and the first entry is False in the vector returned by duplicated.

    Summary for the french names step

    One last thing to do is to remove the pref column which won't be used anymore. We already know how to do it.

    >>> frnames.drop('pref', axis=1, inplace=True)

    There has been a lot of talking until now. But if we summarize, very few commands where needed to obtain this table with only two columns (gid and frname):

    1. Prepare a smaller file so there is less data to load (keep only french names).

      with open('alternateNames.txt') as f:
          reader = csv.reader(f, delimiter='\t', quoting=csv.QUOTE_NONE)
          with open('frAltNames.txt', 'w') as g:
              writer = csv.writer(g, delimiter='\t', quoting=csv.QUOTE_NONE,
              for row in reader:
                  if row[2] == u'fr':
    2. Load the file into Pandas.

      with open('frAltNames.txt') as altf:
          frnames = pd.read_csv(
              altf, encoding='utf-8',
              sep='\t', quoting=csv.QUOTE_NONE,
              header=None, usecols=(1, 3, 4), index_col=0,
              names=('gid', 'frname', 'pref'),
              dtype={'gid': 'uint32', 'frname': str, 'pref': 'bool_'},
              true_values=['1'], false_values=[u''], na_filter=False,
              skipinitialspace=True, error_bad_lines=False
    3. Sort on the pref column and remove duplicated indices.

      frnames.sort_values('pref', ascending=False, inplace=True)
      frnames = frnames[~(frnames.index.duplicated())]
    4. Remove the pref column.

      frnames.drop('pref', axis=1, inplace=True)

    Simple, isn't it ? We'll keep this dataframe for later use. Pandas will make it a breeze to merge it with the main dataframe coming from allCountries.txt to create the new frname column.

    The administrative tree step

    But for now, let's look at the second problem: how to derive a gid from a feature_code, a country_code, and a bunch of adminX_code (X=1, 2, 3, 4).

    Loading file

    First we need the administrative part of the file allCountries.txt, that is all places with the A feature class.

    Of course we can load the whole file into Pandas and then filter to keep only A-class entries, but now you know that this is memory intensive (and this file is much bigger than alternateNames.txt). So we'll be more clever and first prepare a smaller file.

    >>> with open('allCountries.txt') as f:
    ...     reader = csv.reader(f, delimiter='\t', quoting=csv.QUOTE_NONE)
    ...     with open('adm_geonames.txt', 'w') as g:
    ...         writer = csv.writer(g, delimiter='\t', quoting=csv.QUOTE_NONE, escapechar='\\')
    ...         for row in reader:
    ...             if row[6] == 'A':
    ...                 writer.writerow(row)

    Now we load this file into pandas. Remembering our goal, the resulting dataframe will only be used to compute gid from the code columns. So all columns we need are geonameid, feature_code, country_code, admin1_code, admin2_code, admin3_code, and admin4_code.

    What about data types. All these columns are strings except for geonameid which is an integer. Since it will be painful to type <colname>: str for the dtype parameter dictionary, let's use the fromkeys constructor instead.

    >>> d_types = dict.fromkeys(['fcode', 'code0', 'code1', 'code2', 'code3',
    ...                          'code4'], str)
    >>> d_types['gid'] = 'uint32'  # Shorter geonameid in gid

    We can now load the file.

    >>> with open('adm_geonames.txt') as admf:
    ...     admgids = pd.read_csv(
    ...         admf, encoding='utf-8',
    ...         sep='\t', quoting=csv.QUOTE_NONE,
    ...         header=None, usecols=(0, 7, 8, 10, 11, 12, 13),
    ...         names=('gid', 'fcode', 'code0', 'code1', 'code2', 'code3', 'code4'),
    ...         dtype=d_types, na_values='', keep_default_na=False,
    ...         error_bad_lines=False
    ...     )

    We recognize most parameters in this instruction. Notice that we didn't use index_col=0: gid is now a normal column, not an index, and Pandas will generate automatically a row index with integers starting at 0.

    Two new parameters are na_values and keep_default_na. The first one gives Pandas additional strings to be considerer as NaN (Not a Number). The astute reader would say that empty strings ('') are already considered by Pandas as NaN, and he would be right.

    But here comes the second parameter which, if set to False, tells Pandas to forget about its default list of strings recognized as NaN. The default list contains a bunch of strings like 'N/A' or '#NA' or, this is interesting, simply 'NA'. But 'NA' is used in allCountries.txt as country code for Namibia. If we keep the default list, this whole country will be ignored. So the combination of these two parameters tells Pandas to:

    • reset its default list of NaN strings,
    • use '' as a NaN string, which, consequently, will be the only one.

    That's it for NaN. What can Pandas tells us about our dataframe ?

    <class 'pandas.core.frame.DataFrame'>
    RangeIndex: 369277 entries, 0 to 369276
    Data columns (total 7 columns):
    gid      369277 non-null uint32
    fcode    369273 non-null object
    code0    369272 non-null object
    code1    369197 non-null object
    code2    288494 non-null object
    code3    215908 non-null object
    code4    164899 non-null object
    dtypes: object(6), uint32(1)
    memory usage: 128.8 MB

    Note the RangeIndex which Pandas has created for us. The dataframe takes about 130 MB of memory because it has a lots of object columns. Apart from that, everything looks good.

    Replacing values

    One thing we want to do before going on, is to replace all 'PCL<X>' values in the fcode column with just PCL. This will make our life easier later when searching in this dataframe.

    >>> pd.unique(admgids.fcode)
    array([u'ADMD', u'ADM1', u'PCLI', u'ADM2', u'ADM3', u'ADM2H', u'PCLD',
           u'ADM4', u'ZN', u'ADM1H', u'PCLH', u'TERR', u'ADM3H', u'PRSH',
           u'PCLIX', u'ADM5', u'ADMDH', nan, u'PCLS', u'LTER', u'ADM4H',
           u'ZNB', u'PCLF', u'PCL'], dtype=object)

    Pandas provides the replace method for that.

    >>> admgids.replace({'fcode': {r'PCL[A-Z]{1,2}': 'PCL'}}, regex=True, inplace=True)
    >>> pd.unique(admgids.fcode)
    array([u'ADMD', u'ADM1', u'PCL', u'ADM2', u'ADM3', u'ADM2H', u'ADM4',
           u'ZN', u'ADM1H', u'TERR', u'ADM3H', u'PRSH', u'ADM5', u'ADMDH', nan,
           u'LTER', u'ADM4H', u'ZNB'], dtype=object)

    The replace method has lot of different signatures, refer to the Pandas documentation for a comprehensive description. Here, with the dictionary, we hare saying to look only in column fcode, and in this column, replace strings matching the regular expression with the given value. Since we are using regular expressions, the regex parameter must be set to True.

    And as usual, the inplace parameter avoids creation of a copy.


    Remember the goal: we want to be able to get the gid from the others columns. Well, dear reader, you'll be happy to know that Pandas allows an index to be composite, to be composed of multiple columns, what Pandas calls a MultiIndex.

    To put it simply, a multi-index is useful when you have hierarchical indices Consider for example the following table.

    lvl1 lvl2 N S
    A AA 11 1x1
    A AB 12 1x2
    B BA 21 2x1
    B BB 22 2x2
    B BC 33 3x3

    If we were to load such a table in a Pandas dataframe df (exercise: do it), we would be able to use it as follows.

    >>> df.loc['A']
         N    S
    AA  11  1x1
    AB  12  1x2
    >>> df.loc['B']
         N    S
    BA  21  2x1
    BB  22  2x2
    BC  23  2x3
    >>> df.loc[('A',), 'S']
    AA    1x1
    AB    1x2
    Name: S, dtype: object
    >>> df.loc[('A', 'AB'), 'S']
    >>> df.loc['B', 'BB']
    N     22
    S    2x2
    Name: (B, BB), dtype: object
    >>> df.loc[('B', 'BB')]
    N     22
    S    2x2
    Name: (B, BB), dtype: object

    So, basically, we can query the multi-index using tuples (and we can omit tuples if column indexing is not involved). But must importantly we can query a multi-index partially: df.loc['A'] returns a sub-dataframe with one level of index gone.

    Back to our subject, we clearly have hierarchical information in our code columns: the country code, then the admin1 code, then the admin2 code, and so on. Moreover, we can put the feature code at the top. But how to do that ?

    It can't be more simpler. The main issue is to find the correct method: set_index.

    >>> admgids.set_index(['fcode', 'code0', 'code1', 'code2', 'code3', 'code4'],
    ...                    inplace=True)
    <class 'pandas.core.frame.DataFrame'>
    MultiIndex: 369277 entries, (ADMD, AD, 00, nan, nan, nan) to (PCLH, nan, nan, nan, nan, nan)
    Data columns (total 1 columns):
    gid      369277 non-null uint32
    dtypes: uint32(1)
    memory usage: 21.9 MB
    >>> admgids.head()
    fcode code0 code1 code2 code3 code4
    ADMD  AD    00    NaN   NaN   NaN    3038817
                                  NaN    3039039
    ADM1  AD    06    NaN   NaN   NaN    3039162
                05    NaN   NaN   NaN    3039676
                04    NaN   NaN   NaN    3040131

    That's not really it, because Pandas has kept the original dataframe order, so multi-index is all messed up. No problem, there is the sort_index method.

    >>> admgids.sort_index(inplace=True)
    <class 'pandas.core.frame.DataFrame'>
    MultiIndex: 369277 entries, (nan, CA, 10, 02, 94235, nan) to (ZNB, SY, 00, nan, nan, nan)
    Data columns (total 1 columns):
    gid      369277 non-null uint32
    dtypes: uint32(1)
    memory usage: 21.9 MB
    >>> admgids.head()
    fcode code0 code1 code2 code3 code4
    NaN   CA    10    02    94235 NaN    6544163
          CN    NaN   NaN   NaN   NaN    6255000
          CY    04    NaN   NaN   NaN    6640324
          MX    16    NaN   NaN   NaN    6618819
    ADM1  AD    02    NaN   NaN   NaN    3041203

    Much better. We can even see that there are three entries without a feature code.

    Let's see if all this effort was worth it. Can we fulfill our goal ? Can we get a gid from a bunch of codes ? Can we get the Haute-Garonne gid ?

    >>> admgids.loc['ADM2', 'FR', '76', '31']
    code3 code4
    NaN   NaN    3013767

    And for the Toulouse ADM4 ?

    >>> admgids.loc['ADM4', 'FR', '76', '31', '313', '31555']
    fcode code0 code1 code2 code3 code4
    ADM4  FR    76    31    313   31555  6453974

    Cheers! You've deserved a glass of wine!

    Summary for the administrative data step

    Before moving on four our grand finale, let's summarize what have been done to prepare administrative data.

    1. We've prepared a smaller file with only administrative data.

      with open('allCountries.txt') as f:
          reader = csv.reader(f, delimiter='\t', quoting=csv.QUOTE_NONE)
          with open('adm_geonames.txt', 'w') as g:
              writer = csv.writer(g, delimiter='\t', quoting=csv.QUOTE_NONE,
              for row in reader:
                  if row[6] == 'A':
    2. We've loaded the file into Pandas.

      d_types = dict.fromkeys(['fcode', 'code0', 'code1', 'code2', 'code3',
                               'code4'], str)
      d_types['gid'] = 'uint32'
      with open('adm_geonames.txt') as admf:
          admgids = pd.read_csv(
              admf, encoding='utf-8',
              sep='\t', quoting=csv.QUOTE_NONE,
              header=None, usecols=(0, 7, 8, 10, 11, 12, 13),
              names=('gid', 'fcode', 'code0', 'code1', 'code2', 'code3', 'code4'),
              dtype=d_types, na_values='', keep_default_na=False,
    3. We've replaced all 'PCL<XX>' values with just 'PCL' in the fcode column.

      admgids.replace({'fcode': {r'PCL[A-Z]{1,2}': 'PCL'}}, regex=True,
    4. Then we've created a multi-index with columns fcode, code0, code1, code2, code3, code4.

      admgids.set_index(['fcode', 'code0', 'code1', 'code2', 'code3', 'code4'],

    Putting it all together

    Time has finally come to load the main file now: allCountries.txt. On one hand, we will then be able to use the frnames dataframe to get French name for each entry and populate the frname column, and on the other hand we will use the admgids dataframe to compute parent gid for each line too.

    Loading file

    On my computer, loading the whole allCountries.txt at once takes 5.5 GB of memory, clearly too much! And in this case, there is no trick to reduce the size of the file first: we want all the data.

    Pandas can help us with the chunk_size parameter to the read_csv function. It allows us to read the file chunk by chunk (it returns an iterator). The idea is to first create an empty CSV file for our final data, then read each chunk, perform data manipulation (that is add frname and parent_gid) of this chunk, and append the data to the file.

    So we load data into Pandas the usual way. The only difference is that we add a new parameter chunksize with value 1,000,000. You can choose a smaller or a larger number of rows depending of your memory limit.

    >>> d_types = dict.fromkeys(['fclass', 'fcode', 'code0', 'code1',
    ...                          'code2', 'code3', 'code4'], str)
    >>> d_types['gid'] = 'uint32'
    >>> d_types['lat'] = 'float16'
    >>> d_types['lng'] = 'float16'
    >>> with open('allCountries.txt') as geof:
    ...     reader = pd.read_csv(
    ...         geof, encoding='utf-8',
    ...         sep='\t', quoting=csv.QUOTE_NONE,
    ...         header=None, usecols=(0, 1, 4, 5, 6, 7, 8, 10, 11, 12, 13),
    ...         names=('gid', 'name', 'lat', 'lng', 'fclass', 'fcode',
    ...                'code0', 'code1', 'code2', 'code3', 'code4'),
    ...         dtype=d_types, index_col=0,
    ...         na_values='', keep_default_na=False,
    ...         chunksize=1000000, error_bad_lines=False
    ...     )
    ...     for chunk in reader:
    ...         pass  # We will put here code to work on each chunk

    Joining tables

    Pandas can perform a JOIN on two dataframes, much like in SQL. The function to do so is merge.

    ...     for chunk in reader:
    ...         chunk = pd.merge(chunk, frnames, how='left',
    ...                          left_index=True, right_index=True)

    merge expects first the two dataframes to be joined. The how parameter tells what type of JOIN to perform (it can be left, right, inner, ...). Here we wants to keep all lines in chunk, which is the first parameter, so it is 'left' (if chunk was the second parameter, it would have been 'right').

    left_index=True and right_index=True tell Pandas that the pivot column is the index on each table. Indeed, in our case the gid index will be use in both tables to compute the merge. If in one table, for example the right one, the pivot column is not the index, one can set right_index=False and add parameter right_on='<column_name>' (same parameter exists for left table).

    Additionally, If there are name clashes (same column name in both tables), one can also use the suffixes parameter. For example suffixes=('_first', '_second').

    And that's all we need to add the frname column. Simple isn't it ?

    Computing parent gid

    The parent_gid column is trickier. We'll delegate computation of the gid from administrative codes to a separate function. But first let's define two reverse dictionaries linking the fcode column to a level number

    >>> level_fcode = {0: 'PCL', 1: 'ADM1', 2: 'ADM2', 3: 'ADM3', 4: 'ADM4'}
    >>> fcode_level = dict((v, k) for k, v in level_fcode.items())

    And here is the function computing the Geonames id from administrative codes.

    >>> def geonameid_from_codes(level, **codes):
    ...     """Return the Geoname id of the *administrative* place with the
    ...     given information.
    ...     Return ``None`` if there is no match.
    ...     ``level`` is an integer from 0 to 4. 0 means we are looking for a
    ...     political entity (``PCL<X>`` feature code), 1 for a first-level
    ...     administrative division (``ADM1``), and so on until fourth-level
    ...     (``ADM4``).
    ...     Then user must provide at least one of the ``code0``, ...,
    ...     ``code4`` keyword parameters, depending on ``level``.
    ...     Examples::
    ...         >>> geonameid_from_codes(level=0, code0='RE')
    ...         935317
    ...         >>> geonameid_from_codes(level=3, code0='RE', code1='RE',
    ...         ...                      code2='974', code3='9742')
    ...         935213
    ...         >>> geonameid_from_codes(level=0, code0='AB')  # None
    ...     """
    ...     try:
    ...         idx = tuple(codes['code{0}'.format(i)] for i in range(level+1))
    ...     except KeyError:
    ...         raise ValueError('Not enough codeX parameters for level {0}'.format(level))
    ...     idx = (level_fcode[level],) + idx
    ...     try:
    ...         return admgids.loc[idx, 'gid'].values[0]
    ...     except (KeyError, TypeError):
    ...         return None

    A few comments about this function: the first part builds a tuple idx with the given codes. Then this idx is used as an index value in the admgids dataframe to find the matching gid.

    We also need another function which will compute the parent gid for a Pandas row.

    >>> from six import string_types
    >>> def parent_geonameid(row):
    ...     """Return the Geoname id of the parent of the given Pandas row.
    ...     Return ``None`` if we can't find the parent's gid.
    ...     """
    ...     # Get the parent's administrative level (PCL or ADM1, ..., ADM4)
    ...     level = fcode_level.get(row.fcode)
    ...     if (level is None and isinstance(fcode, string_types)
    ...             and len(fcode) >= 3):
    ...         fcode_level.get(row.fcode[:3], 5)
    ...     level = level or 5
    ...     level -= 1
    ...     if level < 0:  # We were on a country, no parent
    ...         return None
    ...     # Compute available codes
    ...     l = list(range(5))
    ...     while l and pd.isnull(row['code{0}'.format(l[-1])]):
    ...         l.pop()  # Remove NaN values backwards from code4
    ...     codes = {}
    ...     for i in l:
    ...         if i > level:
    ...             break
    ...         code_label = 'code{0}'.format(i)
    ...         codes[code_label] = row[code_label]
    ...     try:
    ...         return geonameid_from_codes(level, **codes)
    ...     except ValueError:
    ...         return None

    In this function, we first look at the row fcode to get the row administrative level. If the fcode is ADMX we get the level directly. If it is PCL<X>, we get level 0 from PCL. Else we set it to level 5 to say that it is below level 4. So the parent's level is the found level minus one. And if it is -1, we know that we were on a country and there is no parent.

    Then we compute all available administrative codes, removing codes with NaN values from the end.

    With the level and the codes, we can search for the parent's gid using the previous function.

    Now, how do we use this function. No need for a for loop, Pandas gives us the apply method.

    ...     for chunk in reader:
    ...         # (...) pd.merge as before
    ...         parent_gids = chunk.apply(parent_geonameid, axis=1)

    This will apply the parent_geonameid to each row and return a new Pandas series whose head looks like this.

    2986043     nan
    2993838     nan
    2994701     nan
    3007683     nan
    3017832     nan
    3039162     3041565.0

    None values have been converted to NaN. Thus, integer values have been converted to float (you cannot have NaN within an integer column), and this is not what we want. As a compromise, we are going to convert this into str and suppress the decimal part.

    ...         parent_gids = parent_gid.astype(str)  # no inplace=True here
    ...         parent_gids.replace(r'\.0', '', regex=True, inplace=True)

    We also add a label to the column. That's the name the column in our future dataframe.

    ...         parent_gids = parent_gids.rename('parent_gid')

    And we can now append this new column to our chunk dataframe.

    ...         chunk = pd.concat([chunk, parent_gids], axis=1)

    We're almost there. Before we can save the chunk in a CSV file, we must reorganize its columns to the expected order. For now, the frname and parent_gid columns have been appended at the end of the dataframe.

    ...         chunk = chunk.reindex(columns=['frname', 'name', 'fclass',
    ...                                        'fcode', 'parent_gid', 'lat',
    ...                                        'lng'])

    At last, we save the chunk to the file opened in append mode.

    ...         chunk.to_csv('final.txt', mode='a', encoding='utf-8',
    ...                      quoting=csv.QUOTE_NONE, sep='\t', header=None)

    Caching to speed up

    Currently, creating the new CSV file from Geonames takes hours, and this is not acceptable. There are multiple ways to make thing go faster. One of the most significant change is to cache results of the parent_geonameid function. Indeed, many places in Geonames have the same parent ; computing the parent gid once and caching it sounds like a good idea.

    If you are using Python3, you can simply use the @functools.lru_cache decorator on the parent_geonameid function. But let us try to define our own custom cache.

    >>> from six import string_types
    >>> gid_cache = {}
    >>> def parent_geonameid(row):
    ...     """Return the Geoname id of the parent of the given Pandas row.
    ...     Return ``None`` if we can't find the parent's gid.
    ...     """
    ...     # Get the parent's administrative level (PCL or ADM1, ..., ADM4)
    ...     level = fcode_level.get(row.fcode)
    ...     if (level is None and isinstance(fcode, string_types)
    ...             and len(fcode) >= 3):
    ...         fcode_level.get(row.fcode[:3], 5)
    ...     level = level or 5
    ...     level -= 1
    ...     if level < 0:  # We were on a country, no parent
    ...         return None
    ...     # Compute available codes
    ...     l = list(range(5))
    ...     while l and pd.isnull(row['code{0}'.format(l[-1])]):
    ...         l.pop()  # Remove NaN values backwards from code4
    ...     codes = {}
    ...     code_tuple = [level]
    ...     for i in l:
    ...         if i > level:
    ...             break
    ...         code_label = 'code{0}'.format(i)
    ...         code = row[code_label]
    ...         codes[code_label] = code
    ...         code_tuple.append(code)
    ...     code_tuple = tuple(code_tuple)
    ...     try:
    ...         parent_gid = (gid_cache.get(code_tuple)
    ...                       or geonameid_from_codes(level, **codes))
    ...     except ValueError:
    ...         parent_gid = None
    ...     # Put value in cache if not already to speed up future lookup
    ...     if code_tuple not in gid_cache:
    ...         gid_cache[code_tuple] = parent_gid
    ...     return parent_gid

    The only difference with the previous version is the use of a gid_cache dictionary. Keys for this dictionary are tuples (<level>, <code0>, [[<code1>], ..., <code4>]) (stored in the code_tuple variable), and the corresponding value is the parent gid for this combination of level and codes. Then the returned parent_gid is first looked in this dictionary for a previous cached result, else is computed from the geonameid_from_codes function like before, and the result is cached.

    Summary for the final step

    Let's review what we have done.

    1. We have defined three useful dictionaries. Two to get a level number from a feature code and conversely, and one to cache computation results.

      level_fcode = {0: 'PCL', 1: 'ADM1', 2: 'ADM2', 3: 'ADM3', 4: 'ADM4'}
      fcode_level = dict((v, k) for k, v in level_fcode.items())
      gid_cache = {}
    2. We have defined a function computing a Geoname id from administrative codes.

      def geonameid_from_codes(level, **codes):
          """Return the Geoname id of the *administrative* place with the
          given information.
          Return ``None`` if there is no match.
          ``level`` is an integer from 0 to 4. 0 means we are looking for a
          political entity (``PCL<X>`` feature code), 1 for a first-level
          administrative division (``ADM1``), and so on until fourth-level
          Then user must provide at least one of the ``code0``, ...,
          ``code4`` keyword parameters, depending on ``level``.
              >>> geonameid_from_codes(level=0, code0='RE')
              >>> geonameid_from_codes(level=3, code0='RE', code1='RE',
              ...                      code2='974', code3='9742')
              >>> geonameid_from_codes(level=0, code0='AB')  # None
              idx = tuple(codes['code{0}'.format(i)] for i in range(level+1))
          except KeyError:
              raise ValueError('Not enough codeX parameters for level {0}'.format(level))
          idx = (level_fcode[level],) + idx
              return admgids.loc[idx, 'gid'].values[0]
          except (KeyError, TypeError):
              return None
    3. We have defined a function computing the parent's gid of a Pandas row.

      def parent_geonameid(row):
          """Return the Geoname id of the parent of the given Pandas row.
          Return ``None`` if we can't find the parent's gid.
          # Get the parent's administrative level (PCL or ADM1, ..., ADM4)
          level = fcode_level.get(row.fcode)
          if (level is None and isinstance(fcode, string_types)
                  and len(fcode) >= 3):
              fcode_level.get(row.fcode[:3], 5)
          level = level or 5
          level -= 1
          if level < 0:  # We were on a country, no parent
              return None
          # Compute available codes
          l = list(range(5))
          while l and pd.isnull(row['code{0}'.format(l[-1])]):
              l.pop()  # Remove NaN values backwards from code4
          codes = {}
          code_tuple = [level]
          for i in l:
              if i > level:
              code_label = 'code{0}'.format(i)
              code = row[code_label]
              codes[code_label] = code
          code_tuple = tuple(code_tuple)
              parent_gid = (gid_cache.get(code_tuple)
                            or geonameid_from_codes(level, **codes))
          except ValueError:
              parent_gid = None
          # Put value in cache if not already to speed up future lookup
          if code_tuple not in gid_cache:
              gid_cache[code_tuple] = parent_gid
          return parent_gid
    4. And finally we have loaded the file allCountries.txt into Pandas using chunks of 1,000,000 rows to save memory. For each chunk, we have merged it with the frnames table to add the frname column, and we applied the parent_geonameid function to add the parent_gid column. We then reordered the columns and append the chunk to the final CSV file.

      d_types = dict.fromkeys(['fclass', 'fcode', 'code0', 'code1',
                               'code2', 'code3', 'code4'], str)
      d_types['gid'] = 'uint32'
      d_types['lat'] = 'float16'
      d_types['lng'] = 'float16'
      with open('allCountries.txt') as geof:
          reader = pd.read_csv(
              geof, encoding='utf-8',
              sep='\t', quoting=csv.QUOTE_NONE,
              header=None, usecols=(0, 1, 4, 5, 6, 7, 8, 10, 11, 12, 13),
              names=('gid', 'name', 'lat', 'lng', 'fclass', 'fcode',
                     'code0', 'code1', 'code2', 'code3', 'code4'),
              dtype=d_types, index_col=0,
              na_values='', keep_default_na=False,
              chunksize=1000000, error_bad_lines=False
          for chunk in reader:
              chunk = pd.merge(chunk, frnames, how='left',
                               left_index=True, right_index=True)
              parent_gids = chunk.apply(parent_geonameid, axis=1)
              parent_gids = parent_gids.astype(str)  # no inplace=True here
              parent_gids.replace(r'\.0', '', regex=True, inplace=True)
              parent_gids = parent_gids.rename('parent_gid')
              chunk = pd.concat([chunk, parent_gids], axis=1)
              chunk = chunk.reindex(columns=['frname', 'name', 'fclass',
                                             'fcode', 'parent_gid', 'lat',
              chunk.to_csv('final.txt', mode='a', encoding='utf-8',
                           quoting=csv.QUOTE_NONE, sep='\t', header=None)

    This final part is the longest, because the parent_geonameid function takes some time on each chunk to compute all parents gids. But at the end of the process we'll proudly see a final.txt file with data the way we want it, and without using too much memory... High five!

    What can be improved

    Congratulations! This ends our journey into the Pandas world.

    Regarding Geonames, to be honest, we've only scratch the surface of its complexity. There's so much to be done.

    If you look at the file we've just produced, you'll see plenty of empty values in the parent_gid column. May be our method to get the Geonames id of the parent needs to be improved. May be all those orphan places should be moved inside their countries.

    Another problem lies within Geonames data. France has overseas territories, for example Reunion Island, Geoname id 935,317. This place has feature code PCLD, which means "dependent political entity". And indeed, Reunion Island is not a country and should not appear at the top level of the tree, at the same level as France. So some work should be done here to have Reunion Island linked to France in some way, may be using the until now ignored cc2 column (for "alternate country codes").

    Still another improvement, easier this one, is to have yet another parent level for continents. For this, one can use the file countryInfo.txt, downloadable from the same page.

    Considering speed this time, there is also room for improvements. First, the code itself might be better designed to avoid some tests and for loops. Another possibility is tu use multiprocessing, since each chunk in allCountries.txt isindependent. Processes can put their finished chunk on a queue that a writer process will read to write data in the output file. Another way to go is Cython (see:

  • Understanding Geonames dump

    2017/02/20 by Yann Voté

    The aim of this 2-parts blog post is to show some useful, yet not very complicated, features of the Pandas Python library that are not found in most (numeric oriented) tutorials.

    We will illustrate these techniques with Geonames data : extract useful data from the Geonames dump, transform it, and load it into another file. There is no numeric computation involved here, nor statictics. We will prove that pandas can be used in a wide range of cases beyond numerical analysis.

    This first part is an introduction to Geonames data. The real work with Pandas will be shown on the second part You can skip this part and go directly to part 2 if you are already familiar with Geonames.

    Main data

    Geonames data can be downloaded from The main file to download is Once extracted, you'll get a CSV file named allCountries.txt which contains nearly all Geonames data. In this file, CSV data are separated by tabulation.

    A sample Geonames entry

    Let's look in Geonames data for the city of Toulouse in France.

    $ grep -P '\tToulouse\t' allCountries.txt

    You'll find multiple results (including one in the United States of America), and among them the following line.

    2972315     Toulouse        Toulouse        Gorad Tuluza,Lapangan Terbang Blagnac,TLS,Tolosa,(...)  43.60426        1.44367 P       PPLA    FR              76      31      313     31555   433055          150     Europe/Paris    2016-02-18

    What is the meaning of each column ? There is no header line at the top of the file... Go back to the web page from where you downloaded the file. Below download links, you'll find some documentation. In particular, consider the following excerpt.

    The main 'geoname' table has the following fields :
    geonameid         : integer id of record in geonames database
    name              : name of geographical point (utf8) varchar(200)
    asciiname         : name of geographical point in plain ascii characters, varchar(200)
    alternatenames    : alternatenames, comma separated, ascii names automatically transliterated, convenience attribute from alternatename table, varchar(10000)
    latitude          : latitude in decimal degrees (wgs84)
    longitude         : longitude in decimal degrees (wgs84)
    feature class     : see, char(1)
    feature code      : see, varchar(10)
    country code      : ISO-3166 2-letter country code, 2 characters
    cc2               : alternate country codes, comma separated, ISO-3166 2-letter country code, 200 characters
    admin1 code       : fipscode (subject to change to iso code), see exceptions below, see file admin1Codes.txt for display names of this code; varchar(20)
    admin2 code       : code for the second administrative division, a county in the US, see file admin2Codes.txt; varchar(80)
    admin3 code       : code for third level administrative division, varchar(20)
    admin4 code       : code for fourth level administrative division, varchar(20)
    population        : bigint (8 byte int)
    elevation         : in meters, integer
    dem               : digital elevation model, srtm3 or gtopo30, average elevation of 3''x3'' (ca 90mx90m) or 30''x30'' (ca 900mx900m) area in meters, integer. srtm processed by cgiar/ciat.
    timezone          : the iana timezone id (see file timeZone.txt) varchar(40)
    modification date : date of last modification in yyyy-MM-dd format

    So we see that entry 2,972,315 represents a place named Toulouse, for which latitude is 43.60 and longitude is 1.44. The place is located in France (FR country code), its population is estimated to 433,055, elevation is 150 m, and timezone is the same than Paris.

    To understand the meaning of P and PPLA, as feature class and feature code respectively, the indicated web page at provides us with the following information.

    P city, village,...
    PPLA        seat of a first-order administrative division

    Thus line 2,972,315 is about a city which is the seat of a first-order administrative division in France. And indeed, Toulouse is the seat of the Occitanie region in France.

    Geonames administrative divisions

    So let's look for Occitanie.

    $ grep -P '\tOccitanie\t' allCountries.txt

    You'll end up with the following line.

    11071623    Occitanie       Occitanie       Languedoc-Roussillon-Midi-Pyrenees,(...)        44.02722        1.63559 A       ADM1    FR              76              5626858         188     Europe/Paris    2016-11-16

    This is entry number 11,071,623, and we have latitude, longitude, population, elevation and timezone as usual. The place's class is A and its code is ADM1. Information about these codes can be found in the same previous page.

    A country, state, region,...
    ADM1        first-order administrative division

    This confirms that Occitanie is a first-order administrative division of France.

    Now look at the adminX_code part of the Occitanie line (X=1, 2, 3, 4).


    Only column admin1_code is filled with value 76. Compare this with the same part from the Toulouse line.

    76  31      313     31555

    Here all columns admin1_code, admin2_code, admin3_code and admin4_code are given a value, respectively 76, 31 313, and 31555.

    Furthermore, we see that column admin1_code matches for Occitanie and Toulouse (value 76). This let us deduce that Toulouse is actually a city located in Occitanie.

    So, following the same logic, we can infer that Toulouse is also located in a second-order administrative division of France (feature code ADM2) with admin1_code of 76 and admin2_code equals to 31. Let's look for such a line in allCountries.txt.

    $ grep -P '\tADM2\t' allCountries.txt | grep -P '\tFR\t' | grep -P '\t76\t' \
    > | grep -P '\t31\t'

    We get the following line.

    3013767     Département de la Haute-Garonne Departement de la Haute-Garonne Alta Garonna,Alto Garona,(...)  43.41667        1.5     A       ADM2    FR              76      31                      1254347         181     Europe/Paris    2016-02-18

    Success! Toulouse is actually in the Haute-Garonne department, which is a department in Occitanie region.

    Is this going to work for third-level administrative division ? Let's look for an ADM3 line, with admin1_code=76, admin2_code=31, and admin3_code=313.

    $ grep -P '\tADM3\t' allCountries.txt | grep -P '\tFR\t' | grep -P '\t76\t' \
    > | grep -P '\t31\t' | grep -P '\t313\t'

    Here is the result.

    2972314     Arrondissement de Toulouse      Arrondissement de Toulouse      Arrondissement de Toulouse      43.58333        1.5     A       ADM3    FR              76      31      313             972098          139     Europe/Paris    2016-12-05

    Still works! Finally, let's find out the fourth-order administrative division which contains the city of Toulouse.

    $ grep -P '\tADM4\t' allCountries.txt | grep -P '\tFR\t' | grep -P '\t76\t' \
    > | grep -P '\t31\t' | grep -P '\t313\t' | grep -P '\t31555\t'

    We get a place also named Toulouse.

    6453974     Toulouse        Toulouse        Toulouse        43.60444        1.44194 A       ADM4    FR              76      31      313     31555   440204          153     Europe/Paris    2016-02-18

    That's a surprise. That's because in France, an arrondissement is the smallest administrative division above a city. So for Geonames, city of Toulouse is both an administrative place (feature class A with feature code ADM4) and a populated place (feature class P with feature code PPLA), so there is two different entries with the same name (beware that this may be different for other countries).

    And that's it! We have found the whole hierarchy of administrative divisions above city of Toulouse, thanks to the adminX_code columns: Occitanie, Département de la Haute-Garonne, Arrondissement de Toulouse, Toulouse (ADM4), and Toulouse (PPL).

    That's it, really ? What about the top-most administrative level, the country ? This may not be intuitive: feature codes for countries start with PCL (for political entity).

    $ grep -P '\tPCL' allCountries.txt | grep -P '\tFR\t'

    Among the result, there's only one PCLI, which means independant political entity.

    3017382     Republic of France      Republic of France      An Fhrainc,An Fhraing,(...)     46      2       A       PCLI    FR              00      64768389                543     Europe/Paris    2015-01-08

    Now we have the whole hierarchy, summarized in the following table.

    level name id fclass fcode ccode adm1_code adm2_code adm3_code adm4_code
    country Republic of France 3017382 A PCLI FR        
    level 1 Occitanie 11071623 A ADM1 FR 76      
    level 2 Département de la Haute-Garonne 3013767 A ADM2 FR 76 31    
    level 3 Arrondissement de Toulouse 2972314 A ADM3 FR 76 31 313  
    level 4 Toulouse 6453974 A ADM4 FR 76 31 313 31555
    city Toulouse 2972315 P PPL FR 76 31 313 31555

    Alternate names

    In the previous example, "Republic of France" is the main name for Geonames. But this is not the name in French ("République française"), and even the name in French is not the most commonly used name which is "France".

    In the same way, "Département de la Haute-Garonne" is not the most commonly used name for the department, which is just "Haute-Garonne".

    The fourth column in allCountries.txt provides a comma-separated list of alternate names for a place, in other languages and in other forms. But this is not very useful because we can't decide which form in the list is in which language.

    For this, the Geonames project provides another file to download: Go back to the download page, download it, and extract it. You'll get another tabulation-separeted CSV file named alternateNames.txt.

    Let's look at alternate names for the Haute-Garonne department.

    $ grep -P '\t3013767\t' alternateNames.txt

    Multiple names are printed.

    2080345     3013767 fr      Département de la Haute-Garonne
    2080346     3013767 es      Alto Garona     1       1
    2187116     3013767 fr      Haute-Garonne   1       1
    2431178     3013767 it      Alta Garonna    1       1
    2703076     3013767 en      Upper Garonne   1       1
    2703077     3013767 de      Haute-Garonne   1       1
    3047130     3013767 link
    3074362     3013767 en      Haute Garonne
    4288095     3013767         Département de la Haute-Garonne
    10273497    3013767 link

    To understand these columns, let's look again at the documentation.

    The table 'alternate names' :
    alternateNameId   : the id of this alternate name, int
    geonameid         : geonameId referring to id in table 'geoname', int
    isolanguage       : iso 639 language code 2- or 3-characters; (...)
    alternate name    : alternate name or name variant, varchar(400)
    isPreferredName   : '1', if this alternate name is an official/preferred name
    isShortName       : '1', if this is a short name like 'California' for 'State of California'
    isColloquial      : '1', if this alternate name is a colloquial or slang term
    isHistoric        : '1', if this alternate name is historic and was used in the pastq

    We can see that "Haute-Garonne" is a short version of "Département de la Haute-Garonne" and is the preferred form in French. As an exercise, the reader can confirm in the same way that "France" is the preferred shorter form for "Republic of France" in French.

    And that's it for our introductory journey into Geonames. You are now familiar enough with this data to begin working with it using Pandas in Python. In fact, what we have done until now, namely working with grep commands, is not very useful... See you in part 2!

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


    • 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


  • 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

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

    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.

    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.

    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.

    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.

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

    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.

    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 !

  • SciviJS

    2016/10/10 by Martin Renou


    The goal of my work at Logilab is to create tools to visualize scientific 3D volumic-mesh-based data (mechanical data, electromagnetic...) in a standard web browser. It's a part of the european OpenDreamKit project. Franck Wang has been working on this subject last year. I based my work on his results and tried to improve them.

    Our goal is to create widgets to be used in Jupyter Notebook (formerly IPython) for easy 3D visualization and analysis. We also want to create a graphical user interface in order to enable users to intuitively compute multiple effects on their meshes.

    As Franck Wang worked with X3DOM, which is an open source JavaScript framework that makes it possible to display 3D scenes using HTML nodes, we first thought it was a good idea to keep on working with this framework. But X3DOM is not very well maintained these days, as can be seen on their GitHub repository.

    As a consequence, we decided to take a look at another 3D framework. Our best candidates were:

    • ThreeJS
    • BabylonJS

    ThreeJS and BabylonJS are two well-known Open Source frameworks for 3D web visualization. They are well maintained by hundreds of contributors since several years. Even if BabylonJS was first thought for video games, these two engines are interesting for our project. Some advantages of ThreeJS are:

    Finally, the choice of using ThreeJS was quite obvious because of its Nodes feature, contributed by Sunag Entertainment. It allows users to compose multiple effects like isocolor, threshold, clip plane, etc. As ThreeJS is an Open Source framework, it is quite easy to propose new features and contributors are very helpful.


    As we want to compose multiple effects like isocolor and threshold (the pixel color correspond to a pressure but if this pressure is under a certain threshold we don't want to display it), it seems a good idea to compose shaders instead of creating a big shader with all the features we want to implement. The problem is that WebGL is still limited (as of the 1.x version) and it's not possible for shaders to exchange data with other shaders. Only the vertex shader can send data to the fragment shader through varyings.

    So it's not really possible to compose shaders, but the good news is we can use the new node system of ThreeJS to easily compute and compose a complex material for a mesh.

    alternate text

    It's the graphical view of what you can do in your code, but you can see that it's really simple to implement effects in order to visualize your data.


    With this great tools as a solid basis, I designed a first version of a javascript library, SciviJS, that aims at loading, displaying and analyzing mesh data in a standard web browser (i.e. without any plugin).

    You can define your visualization in a .yml file containing urls to your mesh and data and a hierarchy of effects (called block structures).

    See for an online demo.

    You can see the block structure like following:

    Data blocks are instantiated to load the mesh and define basic parameters like color, position etc. Blocks are connected together to form a tree that helps building a visual analysis of your mesh data. Each block receives data (like mesh variables, color and position) from its parent and can modify them independently.

    Following parameters must be set on dataBlocks:

    • coordURL: URL to the binary file containing coordinate values of vertices.
    • facesURL: URL to the binary file containing indices of faces defining the skin of the mesh.
    • tetrasURL: URL to the binary file containing indices of tetrahedrons. Default is ''.
    • dataURL: URL to the binary file containing data that you want to visualize for each vertices.

    Following parameters can be set on dataBlocks or plugInBlocks:

    • type: type of the block, which is dataBlock or the name of the plugInBlock that you want.
    • colored: define whether or not the 3D object is colored. Default is false, object is rendered gray.
    • colorMap: color map used for coloration, available values are rainbow and gray. Default is rainbow.
    • colorMapMin and colorMapMax: bounds for coloration scaled in [0, 1]. Default is (0, 1).
    • visualizedData: data used as input for coloration. If data are 3D vectors available values are magnitude, X, Y, Z, and default is magnitude. If data are scalar values you don't need to set this parameter.
    • position, rotation, scale: 3D vectors representing position, rotation and scale of the object. Default are [0., 0., 0.], [0., 0., 0.] and [1., 1., 1.].
    • visible: define whether or not the object is visible. Default is true if there's no childrenBlock, false otherwise.
    • childrenBlocks: array of children blocks. Default is empty.

    As of today, there are 6 types of plug-in blocks:

    • Threshold: hide areas of your mesh based on a variable's value and bound parameters

      • lowerBound: lower bound used for threshold. Default is 0 (representing dataMin). If inputData is under lowerBound, then it's not displayed.
      • upperBound: upper bound used for threshold. Default is 1 (representing dataMax). If inputData is above upperBound, then it's not displayed.
      • inputData: data used for threshold effect. Default is visualizedData, but you can set it to magnitude, X, Y or Z.
    • ClipPlane: hide a part of the mesh by cutting it with a plane

      • planeNormal: 3D array representing the normal of the plane used for section. Default is [1., 0., 0.].
      • planePosition: position of the plane for the section. It's a scalar scaled bewteen -1 and 1. Default is 0.
    • Slice: make a slice of your mesh

      • sliceNormal
      • slicePosition
    • Warp: deform the mesh along the direction of an input vector data

      • warpFactor: deformation factor. Default is 1, can be negative.
      • inputData: vector data used for warp effect. Default is data, but you can set it to X, Y or Z to use only one vector component.
    • VectorField: represent the input vector data with arrow glyphs

      • lengthFactor: factor of length of vectors. Default is 1, can be negative.
      • inputData
      • nbVectors: max number of vectors. Default is the number of vertices of the mesh (which is the maximum value).
      • mode: mode of distribution. Default is volume, you can set it to surface.
      • distribution: type of distribution. Default is regular, you can set it to random.
    • Points: represent the data with points

      • pointsSize: size of points in pixels. Default is 3.
      • nbPoints
      • mode
      • distribution

    Using those blocks you can easily render interesting 3D scenes like this:

    Future works

    • Integration to Jupyter Notebook
    • As of today you only can define a .yml file defining the tree of blocks, we plan to develop a Graphical User Interface to enable users to define this tree interactively with drag and drop
    • Support of most file types (for now it only supports binary files)

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

    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)

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

  • ngReact: getting angular and react to work together

    2016/08/03 by Nicolas Chauvat

    ngReact is an Angular module that allows React components to be used in AngularJS applications.

    I had to work on enhancing an Angular-based application and wanted to provide the additionnal functionnality as an isolated component that I could develop and test without messing with a large Angular controller that several other people were working on.

    Here is my Angular+React "Hello World", with a couple gotchas that were not underlined in the documentation and took me some time to figure out.

    To set things up, just run:

    $ mkdir angulareacthello && cd angulareacthello
    $ npm init && npm install --save angular ngreact react react-dom

    Then write into index.html:

    <!doctype html>
                 <title>my angular react demo</title>
         <body ng-app="app" ng-controller="helloController">
                         <input type="text" ng-model="" placeholder="Enter a name here">
                         <h1><react-component name="HelloComponent" props="person" /></h1>
         <script src="node_modules/angular/angular.js"></script>
         <script src="node_modules/react/dist/react.js"></script>
         <script src="node_modules/react-dom/dist/react-dom.js"></script>
         <script src="node_modules/ngreact/ngReact.js"></script>
         // include the ngReact module as a dependency for this Angular app
         var app = angular.module('app', ['react']);
         // define a controller that has the name attribute
         app.controller('helloController', function($scope) {
                 $scope.person = { name: 'you' };
         // define a React component that displays "Hello {name}"
         var HelloComponent = React.createClass({
                 render: function() {
                         return React.DOM.span(null, "Hello ";
         // tell Angular about this React component
         app.value('HelloComponent', HelloComponent);

    I took me time to get a couple things clear in my mind.

    <react-component> is not a React component, but an Angular directive that delegates to a React component. Therefore, you should not expect the interface of this tag to be the same as the one of a React component. More precisely, you can only use the props attribute and can not set your react properties by adding more attributes to this tag. If you want to be able to write something like <react-component firstname="person.firstname" lastname="person.lastname"> you will have to use reactDirective to create a specific Angular directive.

    You have to set an object as the props attribute of the react-component tag, because it will be used as the value of this.props in the code of your React class. For example if you set the props attribute to a string ( instead of person in the above example) , you will have trouble using it on the React side because you will get an object built from the enumeration of the string. Therefore, the above example can not be made simpler. If we had written $ = 'you' we could not have passed it correctly to the react component.

    The above was tested with angular@1.5.8, ngreact@0.3.0, react@15.3.0 and react-dom@15.3.0.

    All in all, it worked well. Thank you to all the developers and contributors of these projects.

  • Testing salt formulas with testinfra

    2016/07/21 by Philippe Pepiot

    In a previous post we talked about an environment to develop salt formulas. To add some spicy requirements, the formula must now handle multiple target OS (Debian and Centos), have tests and a continuous integration (CI) server setup.

    I started a year ago to write a framework to this purpose, it's called testinfra and is used to execute commands on remote systems and make assertions on the state and the behavior of the system. The modules API provides a pythonic way to inspect the system. It has a smooth integration with pytest that adds some useful features out of the box like parametrization to run tests against multiple systems.

    Writing useful tests is not an easy task, my advice is to test code that triggers implicit actions, code that has caused issues in the past or simply test the application is working correctly like you would do in the shell.

    For instance this is one of the tests I wrote for the saemref formula

    def test_saemref_running(Process, Service, Socket, Command):
        assert Service("supervisord").is_enabled
        supervisord = Process.get(comm="supervisord")
        # Supervisor run as root
        assert supervisord.user == "root"
        assert == "root"
        cubicweb = Process.get(
        # Cubicweb should run as saemref user
        assert cubicweb.user == "saemref"
        assert == "saemref"
        assert cubicweb.comm == "uwsgi"
        # Should have 2 worker process with 8 thread each and 1 http proccess with one thread
        child_threads = sorted([c.nlwp for c in Process.filter(])
        assert child_threads == [1, 8, 8]
        # uwsgi should bind on all ipv4 adresses
        assert Socket("tcp://").is_listening
        html = Command.check_output("curl http://localhost:8080")
        assert "<title>accueil (Référentiel SAEM)</title>" in html

    Now we can run tests against a running container by giving its name or docker id to testinfra:

    % testinfra --hosts=docker://1a8ddedf8164
    test/[docker:/1a8ddedf8164] PASSED

    The immediate advantage of writing such test is that you can reuse it for monitoring purpose, testinfra can behave like a nagios plugin:

    % testinfra -qq --nagios --hosts=ssh://prod
    TESTINFRA OK - 1 passed, 0 failed, 0 skipped in 2.31 seconds

    We can now integrate the test suite in our by adding some code to build and run a provisioned docker image and add a test command that runs testinfra tests against it.

    provision_option = click.option('--provision', is_flag=True, help="Provision the container")
    @cli.command(help="Build an image")
    def build(image, provision=False):
        dockerfile = "test/{0}.Dockerfile".format(image)
        tag = "{0}-formula:{1}".format(formula, image)
        if provision:
            dockerfile_content = open(dockerfile).read()
            dockerfile_content += "\n" + "\n".join([
                "ADD test/minion.conf /etc/salt/minion.d/minion.conf",
                "ADD {0} /srv/formula/{0}".format(formula),
                "RUN salt-call --retcode-passthrough state.sls {0}".format(formula),
            ]) + "\n"
            dockerfile = "test/{0}_provisioned.Dockerfile".format(image)
            with open(dockerfile, "w") as f:
            tag += "-provisioned"
        subprocess.check_call(["docker", "build", "-t", tag, "-f", dockerfile, "."])
        return tag
    @cli.command(help="Spawn an interactive shell in a new container")
    def dev(ctx, image, provision=False):
        tag = ctx.invoke(build, image=image, provision=provision)[
            "docker", "run", "-i", "-t", "--rm", "--hostname", image,
            "-v", "{0}/test/minion.conf:/etc/salt/minion.d/minion.conf".format(BASEDIR),
            "-v", "{0}/{1}:/srv/formula/{1}".format(BASEDIR, formula),
            tag, "/bin/bash",
    @cli.command(help="Run tests against a provisioned container",
                 context_settings={"allow_extra_args": True})
    def test(ctx, image):
        import pytest
        tag = ctx.invoke(build, image=image, provision=True)
        docker_id = subprocess.check_output([
            "docker", "run", "-d", "--hostname", image,
            "-v", "{0}/test/minion.conf:/etc/salt/minion.d/minion.conf".format(BASEDIR),
            "-v", "{0}/{1}:/srv/formula/{1}".format(BASEDIR, formula),
            tag, "tail", "-f", "/dev/null",
            ctx.exit(pytest.main(["--hosts=docker://" + docker_id] + ctx.args))
            subprocess.check_call(["docker", "rm", "-f", docker_id])

    Tests can be run on a local CI server or on travis, they "just" require a docker server, here is an example of .travis.yml

    sudo: required
      - docker
    language: python
      - "2.7"
        - IMAGE=centos7
        - IMAGE=jessie
      - pip install testinfra
      - python test $IMAGE -- -v

    I wrote a dummy formula with the above code, feel free to use it as a template for your own formula or open pull requests and break some tests.

    There is a highly enhanced version of this code in the saemref formula repository, including:

    • Building a provisioned docker image with custom pillars, we use it to run an online demo
    • Destructive tests where each test is run in a dedicated "fresh" container
    • Run Systemd in the containers to get a system close to the production one (this enables the use of Salt service module)
    • Run a postgresql container linked to the tested container for specific tests like upgrading a Cubicweb instance.

    Destructive tests rely on advanced pytest features that may produce weird bugs when mixed together, too much magic involved here. Also, handling Systemd in docker is really painful and adds a lot of complexity, for instance some systemctl commands require a running systemd as PID 1 and this is not the case during the docker build phase. So the trade-off between complexity and these features may not be worth.

    There is also a lot of quite new tools to develop and test infrastructure code that you could include in your stack like test-kitchen, serverspec, and goss. Choose your weapon and go test your infrastructure code.

  • Developing salt formulas with docker

    2016/07/21 by Philippe Pepiot

    While developing salt formulas I was looking for a simple and reproducible environment to allow faster development, less bugs and more fun. The formula must handle multiple target OS (Debian and Centos).

    The first barrier is the master/minion installation of Salt, but fortunately Salt has a masterless mode. The idea is quite simple, bring up a virtual machine, install a Salt minion on it, expose the code inside the VM and call Salt states.

    At Logilab we like to work with docker, a lightweight OS-level virtualization solution. One of the key features is docker volumes to share local files inside the container. So I started to write a simple Python script to build a container with a Salt minion installed and run it with formula states and a few config files shared inside the VM.

    The formula I was working on is used to deploy the saemref project, which is a Cubicweb based application:

    % cat test/centos7.Dockerfile
    FROM centos:7
    RUN yum -y install epel-release && \
        yum -y install && \
        yum clean expire-cache && \
        yum -y install salt-minion
    % cat test/jessie.Dockerfile
    FROM debian:jessie
    RUN apt-get update && apt-get -y install wget
    RUN wget -O - | apt-key add -
    RUN echo "deb jessie main" > /etc/apt/sources.list.d/saltstack.list
    RUN apt-get update && apt-get -y install salt-minion
    % cat test/minion.conf
    file_client: local
        - /srv/salt
        - /srv/formula

    And finally the file, using the beautiful click module

    #!/usr/bin/env python
    import os
    import subprocess
    import click
    def cli():
    formula = "saemref"
    BASEDIR = os.path.abspath(os.path.dirname(__file__))
    image_choice = click.argument("image", type=click.Choice(["centos7", "jessie"]))
    @cli.command(help="Build an image")
    def build(image):
        dockerfile = "test/{0}.Dockerfile".format(image)
        tag = "{0}-formula:{1}".format(formula, image)
        subprocess.check_call(["docker", "build", "-t", tag, "-f", dockerfile, "."])
        return tag
    @cli.command(help="Spawn an interactive shell in a new container")
    def dev(ctx, image):
        tag = ctx.invoke(build, image=image)[
            "docker", "run", "-i", "-t", "--rm", "--hostname", image,
            "-v", "{0}/test/minion.conf:/etc/salt/minion.d/minion.conf".format(BASEDIR),
            "-v", "{0}/{1}:/srv/formula/{1}".format(BASEDIR, formula),
            tag, "/bin/bash",
    if __name__ == "__main__":

    Now I can run quickly multiple containers and test my Salt states inside the containers while editing the code locally:

    % ./ dev centos7
    [root@centos7 /]# salt-call state.sls saemref
    [ ... ]
    [root@centos7 /]# ^D
    % # The container is destroyed when it exits

    Notice that we could add some custom pillars and state files simply by adding specific docker shared volumes.

    With a few lines we created a lightweight vagrant like, but faster, with docker instead of virtualbox and it remain fully customizable for future needs.

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

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

    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.


    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.

    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 :

    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 !

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

  • Introduction to thesauri and SKOS

    2016/06/27 by Yann Voté

    Recently, I've faced the problem to import the European Union thesaurus, Eurovoc, into cubicweb using the SKOS cube. Eurovoc doesn't follow the SKOS data model and I'll show here how I managed to adapt Eurovoc to fit in SKOS.

    This article is in two parts:

    • this is the first part where I introduce what a thesaurus is and what SKOS is,
    • the second part will show how to convert Eurovoc to plain SKOS.

    The whole text assumes familiarity with RDF, as describing RDF would require more than a blog entry and is out of scope.

    What is a thesaurus ?

    A common need in our digital lives is to attach keywords to documents, web pages, pictures, and so on, so that search is easier. For example, you may want to add two keywords:

    • lily,
    • lilium

    in a picture's metadata about this flower. If you have a large collection of flower pictures, this will make your life easier when you want to search for a particular species later on.

    free-text keywords on a picture

    In this example, keywords are free: you can choose whatever keyword you want, very general or very specific. For example you may just use the keyword:

    • flower

    if you don't care about species. You are also free to use lowercase or uppercase letters, and to make typos...

    free-text keyword on a picture

    On the other side, sometimes you have to select keywords from a list. Such a constrained list is called a controlled vocabulary. For instance, a very simple controlled vocabulary with only two keywords is the one about a person's gender:

    • male (or man),
    • female (or woman).
    a simple controlled vocabulary

    But there are more complex examples: think about how a library organizes books by themes: there are very general themes (eg. Science), then more and more specific ones (eg. Computer science -> Software -> Operating systems). There may also be synonyms (eg. Computing for Computer science) or referrals (eg. there may be a "see also" link between keywords Algebra and Geometry). Such a controlled vocabulary where keywords are organized in a tree structure, and with relations like synonym and referral, is called a thesaurus.

    an example thesaurus with a tree of keywords

    For the sake of simplicity, in the following we will call thesaurus any controlled vocabulary, even a simple one with two keywords like male/female.


    SKOS, from the World Wide Web Consortium (W3C), is an ontology for the semantic web describing thesauri. To make it simple, it is a common data model for thesauri that can be used on the web. If you have a thesaurus and publish it on the web using SKOS, then anyone can understand how your thesaurus is organized.

    SKOS is very versatile. You can use it to produce very simple thesauri (like male/female) and very complex ones, with a tree of keywords, even in multiple languages.

    To cope with this complexity, SKOS data model splits each keyword into two entities: a concept and its labels. For example, the concept of a male person have multiple labels: male and man in English, homme and masculin in French. The concept of a lily flower also has multiple labels: lily in English, lilium in Latin, lys in French.

    Among all labels for a given concept, some can be preferred, while others are alternative. There may be only one preferred label per language. In the person's gender example, man may be the preferred label in English and male an alternative one, while in French homme would be the preferred label and masculin and alternative one. In the flower example, lily (resp. lys) is the preferred label in English (resp. French), and lilium is an alternative label in Latin (no preferred label in Latin).

    SKOS concepts and labels

    And of course, in SKOS, it is possible to say that a concept is broader than another one (just like topic Science is broader than topic Computer science).

    So to summarize, in SKOS, a thesaurus is a tree of concepts, and each concept have one or more labels, preferred or alternative. A thesaurus is also called a concept scheme in SKOS.

    Also, please note that SKOS data model is slightly more complicated than what we've shown here, but this will be sufficient for our purpose.

    RDF URIs defined by SKOS

    In order to publish a thesaurus in RDF using SKOS ontology, SKOS introduces the "skos:" namespace associated to the following URI:

    Within that namespace, SKOS defines some classes and predicates corresponding to what has been described above. For example:

    • the triple (<uri>, rdf:type, skos:ConceptScheme) says that <uri> belongs to class skos:ConceptScheme (that is, is a concept scheme),
    • the triple (<uri>, rdf:type, skos:Concept) says that <uri> belongs to class skos:Concept (that is, is a concept),
    • the triple (<uri>, skos:prefLabel, <literal>) says that <literal> is a preferred label for concept <uri>,
    • the triple (<uri>, skos:altLabel, <literal>) says that <literal> is an alternative label for concept <uri>,
    • the triple (<uri1>, skos:broader, <uri2>) says that concept <uri2> is a broder concept of <uri1>.

  • One way to convert Eurovoc into plain SKOS

    2016/06/27 by Yann Voté

    This is the second part of an article where I show how to import the Eurovoc thesaurus from the European Union into an application using a plain SKOS data model. I've recently faced the problem of importing Eurovoc into CubicWeb using the SKOS cube, and the solution I've chose is discussed here.

    The first part was an introduction to thesauri and SKOS.

    The whole article assumes familiarity with RDF, as describing RDF would require more than a blog entry and is out of scope.

    Difficulties with Eurovoc and SKOS


    Eurovoc is the main thesaurus covering European Union business domains. It is published and maintained by the EU commission. It is quite complex and big, structured as a tree of keywords.

    You can see Eurovoc keywords and browse the tree from the Eurovoc homepage using the link Browse the subject-oriented version.

    For example, when publishing statistics about education in the EU, you can tag the published data with the broadest keyword Education and communications. Or you can be more precise and use the following narrower keywords, in increasing order of preference: Education, Education policy, Education statistics.

    Problem: hierarchy of thesauri

    The EU commission uses SKOS to publish its Eurovoc thesaurus, so it should be straightforward to import Eurovoc into our own application. But things are not that simple...

    For some reasons, Eurovoc uses a hierarchy of concept schemes. For example, Education and communications is a sub-concept scheme of Eurovoc (it is called a domain), and Education is a sub-concept scheme of Education and communications (it is called a micro-thesaurus). Education policy is (a label of) the first concept in this hierarchy.

    But with SKOS this is not possible: a concept scheme cannot be contained into another concept scheme.

    Possible solutions

    So to import Eurovoc into our SKOS application, and not loose data, one solution is to turn sub-concept schemes into concepts. We have two strategies:

    • keep only one concept scheme (Eurovoc) and turn domains and micro-thesauri into concepts,
    • keep domains as concept schemes, drop Eurovoc concept scheme, and only turn micro-thesauri into concepts.

    Here we will discuss the latter solution.

    Lets get to work

    Eurovoc thesaurus can be downloaded at the following URL:

    The ZIP archive contains only one XML file named eurovoc_skos.rdf. Put it somewhere where you can find it easily.

    To read this file easily, we will use the RDFLib Python library. This library makes it really convenient to work with RDF data. It has only one drawback: it is very slow. Reading the whole Eurovoc thesaurus with it takes a very long time. Make the process faster is the first thing to consider for later improvements.

    Reading the Eurovoc thesaurus is as simple as creating an empty RDF Graph and parsing the file. As said above, this takes a long long time (from half an hour to two hours).

    import rdflib
    eurovoc_graph = rdflib.Graph()
    eurovoc_graph.parse('<path/to/eurovoc_skos.rdf>', format='xml')
    <Graph identifier=N52834ca3766d4e71b5e08d50788c5a13 (<class 'rdflib.graph.Graph'>)>

    We can see that Eurovoc contains more than 2 million triples.


    Now, before actually converting Eurovoc to plain SKOS, lets introduce some helper functions:

    • the first one, uriref(), will allow us to build RDFLib URIRef objects from simple prefixed URIs like skos:prefLabel or dcterms:title,
    • the second one, capitalized_eurovoc_domains(), is used to convert Eurovoc domain names, all uppercase (eg. 32 EDUCATION ET COMMUNICATION) to a string where only first letter is uppercase (eg. 32 Education and communication)
    import re
    from rdflib import Literal, Namespace, RDF, URIRef
    from rdflib.namespace import DCTERMS, SKOS
    eu_ns = Namespace('')
    thes_ns = Namespace('')
    prefixes = {
        'dcterms': DCTERMS,
        'skos': SKOS,
        'eu': eu_ns,
        'thes': thes_ns,
    def uriref(prefixed_uri):
        prefix, value = prefixed_uri.split(':', 1)
        ns = prefixes[prefix]
        return ns[value]
    def capitalized_eurovoc_domain(domain):
        """Return the given Eurovoc domain name with only the first letter uppercase."""
        return re.sub(r'^(\d+\s)(.)(.+)$',
                      lambda m: u'{0}{1}{2}'.format(,,,
                      domain, re.UNICODE)

    Now the actual work. After using variables to reference URIs, the loop will parse each triple in original graph and:

    • discard it if it contains deprecated data,
    • if triple is like (<uri>, rdf:type, eu:Domain), replace it with (<uri>, rdf:type, skos:ConceptScheme),
    • if triple is like (<uri>, rdf:type, eu:MicroThesaurus), replace it with (<uri>, rdf:type, skos:Concept) and add triple (<uri>, skos:inScheme, <domain_uri>),
    • if triple is like (<uri>, rdf:type, eu:ThesaurusConcept), replace it with (<uri>, rdf:type, skos:Concept),
    • if triple is like (<uri>, skos:topConceptOf, <microthes_uri>), replace it with (<uri>, skos:broader, <microthes_uri>),
    • if triple is like (<uri>, skos:inScheme, <microthes_uri>), replace it with (<uri>, skos:inScheme, <domain_uri>),
    • keep triples like (<uri>, skos:prefLabel, <label_uri>), (<uri>, skos:altLabel, <label_uri>), and (<uri>, skos:broader, <concept_uri>),
    • discard all other non-deprecated triples.

    Note that, to replace a micro thesaurus with a domain, we have to build a mapping between each micro thesaurus and its containing domain (microthes2domain dict).

    This loop is also quite long.

    eurovoc_ref = URIRef(u'')
    deprecated_ref = URIRef(u'')
    title_ref = uriref('dcterms:title')
    status_ref = uriref('thes:status')
    class_domain_ref = uriref('eu:Domain')
    rel_domain_ref = uriref('eu:domain')
    microthes_ref = uriref('eu:MicroThesaurus')
    thesconcept_ref = uriref('eu:ThesaurusConcept')
    concept_scheme_ref = uriref('skos:ConceptScheme')
    concept_ref = uriref('skos:Concept')
    pref_label_ref = uriref('skos:prefLabel')
    alt_label_ref = uriref('skos:altLabel')
    in_scheme_ref = uriref('skos:inScheme')
    broader_ref = uriref('skos:broader')
    top_concept_ref = uriref('skos:topConceptOf')
    microthes2domain = dict((mt, next(eurovoc_graph.objects(mt, uriref('eu:domain'))))
                            for mt in eurovoc_graph.subjects(RDF.type, uriref('eu:MicroThesaurus')))
    new_graph = rdflib.ConjunctiveGraph()
    for subj_ref, pred_ref, obj_ref in eurovoc_graph:
        if deprecated_ref in list(eurovoc_graph.objects(subj_ref, status_ref)):
        # Convert eu:Domain into a skos:ConceptScheme
        if obj_ref == class_domain_ref:
            new_graph.add((subj_ref, RDF.type, concept_scheme_ref))
            for title in eurovoc_graph.objects(subj_ref, pref_label_ref):
                if title.language == u'en':
                    new_graph.add((subj_ref, title_ref,
        # Convert eu:MicroThesaurus into a skos:Concept
        elif obj_ref == microthes_ref:
            new_graph.add((subj_ref, RDF.type, concept_ref))
            scheme_ref = next(eurovoc_graph.objects(subj_ref, rel_domain_ref))
            new_graph.add((subj_ref, in_scheme_ref, scheme_ref))
        # Convert eu:ThesaurusConcept into a skos:Concept
        elif obj_ref == thesconcept_ref:
            new_graph.add((subj_ref, RDF.type, concept_ref))
        # Replace <concept> topConceptOf <MicroThesaurus> by <concept> broader <MicroThesaurus>
        elif pred_ref == top_concept_ref:
            new_graph.add((subj_ref, broader_ref, obj_ref))
        # Replace <concept> skos:inScheme <MicroThes> by <concept> skos:inScheme <Domain>
        elif pred_ref == in_scheme_ref and obj_ref in microthes2domain:
            new_graph.add((subj_ref, in_scheme_ref, microthes2domain[obj_ref]))
        # Keep label triples
        elif (subj_ref != eurovoc_ref and obj_ref != eurovoc_ref
              and pred_ref in (pref_label_ref, alt_label_ref)):
            new_graph.add((subj_ref, pred_ref, obj_ref))
        # Keep existing skos:broader relations and existing concepts
        elif pred_ref == broader_ref or obj_ref == concept_ref:
            new_graph.add((subj_ref, pred_ref, obj_ref))

    We can check that we now have far less triples than before.


    Now we dump this new graph to disk. We choose the Turtle format as it is far more readable than RDF/XML for humans, and slightly faster to parse for machines. This file will contain plain SKOS data that can be directly imported into any application able to read SKOS.

    with open('eurovoc.n3', 'w') as f:
        new_graph.serialize(f, format='n3')

    With CubicWeb using the SKOS cube, it is a one command step:

    cubicweb-ctl skos-import --cw-store=massive <instance_name> eurovoc.n3

  • Installing Debian Jessie on a "pure UEFI" system

    2016/06/13 by David Douard

    At the core of the Logilab infrastructure is a highly-available pair of small machines dedicated to our main directory and authentication services: LDAP, DNS, DHCP, Kerberos and Radius.

    The machines are small fanless boxes powered by a 1GHz Via Eden processor, 512Mb of RAM and 2Gb of storage on a CompactFlash module.

    They have served us well for many years, but now is the time for an improvement. We've bought a pair of Lanner FW-7543B that have the same form-factor. They are not fanless, but are much more powerful. They are pretty nice, but have one major drawback: their firmware does not boot on a legacy BIOS-mode device when set up in UEFI. Another hard point is that they do not have a video connector (there is a VGA output on the motherboard, but the connector is optional), so everything must be done via the serial console.

    I knew the Debian Jessie installer would provide everything that is required to handle an UEFI-based system, but it took me a few tries to get it to boot.

    First, I tried the standard netboot image, but the firmware did not want to boot from a USB stick, probably because the image requires a MBR-based bootloader.

    Then I tried to boot from the Refind bootable image and it worked! At least I had the proof this little beast could boot in UEFI. But, although it is probably possible, I could not figure out how to tweak the Refind config file to make it boot properly the Debian installer kernel and initrd.

    Finally I gave a try to something I know much better: Grub. Here is what I did to have a working UEFI Debian installer on a USB key.


    First, in the UEFI world, you need a GPT partition table with a FAT partition typed "EFI System":

    david@laptop:~$ sudo fdisk /dev/sdb
    Welcome to fdisk (util-linux 2.25.2).
    Changes will remain in memory only, until you decide to write them.
    Be careful before using the write command.
    Command (m for help): g
    Created a new GPT disklabel (GUID: 52FFD2F9-45D6-40A5-8E00-B35B28D6C33D).
    Command (m for help): n
    Partition number (1-128, default 1): 1
    First sector (2048-3915742, default 2048): 2048
    Last sector, +sectors or +size{K,M,G,T,P} (2048-3915742, default 3915742):  +100M
    Created a new partition 1 of type 'Linux filesystem' and of size 100 MiB.
    Command (m for help): t
    Selected partition 1
    Partition type (type L to list all types): 1
    Changed type of partition 'Linux filesystem' to 'EFI System'.
    Command (m for help): p
    Disk /dev/sdb: 1.9 GiB, 2004877312 bytes, 3915776 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: gpt
    Disk identifier: 52FFD2F9-45D6-40A5-8E00-B35B28D6C33D
    Device     Start    End Sectors  Size Type
    /dev/sdb1   2048 206847  204800  100M EFI System
    Command (m for help): w

    Install Grub

    Now we need to install a grub-efi bootloader in this partition:

    david@laptop:~$ pmount sdb1
    david@laptop:~$ sudo grub-install --target x86_64-efi --efi-directory /media/sdb1/ --removable --boot-directory=/media/sdb1/boot
    Installing for x86_64-efi platform.
    Installation finished. No error reported.

    Copy the Debian Installer

    Our next step is to copy the Debian's netboot kernel and initrd on the USB key:

    david@laptop:~$ mkdir /media/sdb1/EFI/debian
    david@laptop:~$ wget -O /media/sdb1/EFI/debian/linux
    --2016-06-13 18:40:02--  /images/netboot/debian-installer/amd64/linux
    Resolving (, 2a01:e0c:1:1598::2
    Connecting to (||:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 3120416 (3.0M) [text/plain]
    Saving to: ‘/media/sdb1/EFI/debian/linux’
    /media/sdb1/EFI/debian/linux      100%[========================================================>]   2.98M      464KB/s   in 6.6s
    2016-06-13 18:40:09 (459 KB/s) - ‘/media/sdb1/EFI/debian/linux’ saved [3120416/3120416]
    david@laptop:~$ wget -O /media/sdb1/EFI/debian/initrd.gz
    --2016-06-13 18:41:30--
    Resolving (, 2a01:e0c:1:1598::2
    Connecting to (||:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 15119287 (14M) [application/x-gzip]
    Saving to: ‘/media/sdb1/EFI/debian/initrd.gz’
    /media/sdb1/EFI/debian/initrd.g    100%[========================================================>]  14.42M    484KB/s   in 31s
    2016-06-13 18:42:02 (471 KB/s) - ‘/media/sdb1/EFI/debian/initrd.gz’ saved [15119287/15119287]

    Configure Grub

    Then, we must write a decent grub.cfg file to load these:

    david@laptop:~$ echo >/media/sdb1/boot/grub/grub.cfg <<EOF
    menuentry "Jessie Installer" {
      insmod part_msdos
      insmod ext2
      insmod part_gpt
      insmod fat
      insmod gzio
      echo  'Loading Linux kernel'
      linux /EFI/debian/linux --- console=ttyS0,115200
      echo 'Loading InitRD'
      initrd /EFI/debian/initrd.gz

    Et voilà, piece of cake!

  • J'étais au raid agile #5 !

    2016/05/10 by Laura Médioni

    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.

    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.

    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 ; 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 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

  • Our work for the OpenDreamKit project during the 77th Sage days

    2016/04/18 by Florent Cayré

    Logilab is part of OpenDreamKit, a Horizon 2020 European Research Infrastructure project that will run until 2019 and provides substantial funding to the open source computational mathematics ecosystem.

    One of the goals of this project is improve the packaging and documentation of SageMath, the open source alternative to Maple and Mathematica.

    The core developers of SageMath organised the 77th Sage days last week and Logilab has taken part, with David Douard, Julien Cristau and I, Florent Cayre.

    David and Julien have been working on packaging SageMath for Debian. This is a huge task (several man-months of work), split into two sub-tasks for now:

    • building SageMath with Debian-packaged versions of its dependencies, if available;
    • packaging some of the missing dependencies, starting with the most expected ones, like the latest releases of Jupyter and IPython.

    As a first result, the following packages have been pushed into Debian experimental:

    There is still a lot of work to be done, and packaging the notebook is the next task on the list.

    One hiccup along the way was a python crash involving multiple inheritance from Cython extensions classes. Having people nearby who knew the SageMath codebase well (or even wrote the relevant parts) was invaluable for debugging, and allowed us to blame a recent CPython change.

    Julien also gave a hand to Florent Hivert and Robert Lehmann who were trying to understand why building SageMath's documentation needed this much memory.

    As far as I am concerned, I made a prototype of a structured HTML documentation produced with Sphinx and containing Python executable code ran on thanks to the Thebe javascript library that interfaces statically delivered HTML pages with a Jupyter notebook server.

    The Sage days have been an excellent opportunity to efficiently work on the technical tasks with skillfull and enthusiastic people. We would like to thank the OpenDreamKit core team for the organization and their hard work. We look forward to the next workshop.

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


    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!".


    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.

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

    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.

    (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).

    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 ?

    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 :

    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.

  • 3D Visualization of simulation data with x3dom

    2016/02/16 by Yuanxiang Wang

    X3DOM Plugins

    As part of the Open Dream Kit project, we are working at Logilab on the creation of tools for mesh data visualization and analysis in a web application. Our goal was to create widgets to use in Jupyter notebook (formerly IPython) for 3D visualization and analysis.

    We found two interesting technologies for 3D rendering: ThreeJS and X3DOM. ThreeJS is a large JavaScript 3D library and X3DOM a HTML5 framework for 3D. After working with both, we chose to use X3DOM because of its high level architecture. With X3DOM the 3D model is defined in the DOM in HTML5, so the parameters of the nodes can be changed easily with the setAttribute DOM function. This makes the creation of user interfaces and widgets much easier.

    We worked to create new DOM nodes that integrate nicely in a standard X3DOM tree, namely IsoColor, Threshold and ClipPlane.

    We had two goals in mind:

    1. create an X3DOM plugin API that allows one to create new DOM nodes which extend X3DOM functionality;
    2. keep a simple X3DOM-like interface for the final users.

    Example of the plugins Threshold and IsoColor:


    The Threshold and IsoColor nodes work like any X3DOM node and react to attribute changes performed with the setAttribute method. This makes it easy to use HTML widgets like sliders / buttons to drive the plugin's parameters.

    X3Dom API

    The goal is to create custom nodes that affect the rendering based on data (positions, pressure, temperature...). The idea is to manipulate the shaders, since it gives low-level manipulation on the 3D rendering. Shaders give more freedom and efficiency compared to reusing other X3DOM nodes. (Reminder : Shaders are parts of GLSL, used to work with the GPU).

    X3DOM has a native node to all users to write shaders : the ComposedShader node. The problem of this node is it overwrites the shaders generated by X3DOM. For example, nodes like ClipPlane are disabled with a ComposedShader node in the DOM. Another example is image texturing, the computation of the color from texture coordinate should be written within the ComposedShader.

    In order to add parts of shader to the generated shader without overwriting it I created a new node: CustomAttributeNode. This node is a generic node to add uniforms, varying and shader parts into X3DOW. The data of the geometry (attributes) are set using the X3DOM node named FloatVertexAttribute.

    Example of CustomAttributeNode to create a threshold node:


    The CustomAttributeNode is the entry point in x3dom for the javascript API.

    JavaScript API

    The idea of the the API is to create a new node inherited from CustomAttributeNode. We wrote some functions to make the implementation of the node easier.

    Ideas for future improvement

    There are still some points that need improvement

    • Create a tree widget using the grouping nodes in X3DOM
    • Add high level functions to X3DGeometricPropertyNode to set the values. For instance the IsoColor node is only a node that set the values of the TextureCoordinate node from the FloatVertexAttribute node.
    • Add high level function to return the variable name needed to overwrite the basic attributes like positions in a Geometry. With my API, the IsoColor use a varying defined in X3DOM to overwrite the values of the texture coordinate. Because there are no documentation, it is hard for the users to find the varying names. On the other hand there are no specification on the varying names so it might need to be maintained.
    • Maybe the CustomAttributeNode should be a X3DChildNode instead of a X3DGeometricPropertyNode.


    This structure might allow the "use" attribute in X3DOM. Like that, X3DOM avoid data duplication and writing too much HTML. The following code illustrate what I expect.


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

    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.

    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.

    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.

    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 !

  • We went to cfgmgmtcamp 2016 (after FOSDEM)

    2016/02/09 by Arthur Lutz

    Following a day at FOSDEM (another post about it), we spend two days at cfgmgmtcamp in Gent. At cfgmgmtcamp, we obviously spent some time in the Salt track since it's our tool of choice as you might have noticed. But checking out how some of the other tools and communities are finding solutions to similar problems is also great.

    cfgmgmtcamp logo

    I presented Roll out active Supervision with Salt, Graphite and Grafana (mirrored on slideshare), you can find the code on bitbucket.

    We saw :

    Day 1

    • Mark Shuttleworth from Canonical presenting Juju and its ecosystem, software modelling. MASS (Metal As A Service) was demoed on the nice "OrangeBox". It promises to spin up an OpenStack infrastructure in 15 minutes. One of the interesting things with charms and bundles of charms is the interfaces that need to be established between different service bricks. In the salt community we have salt-formulas but they lack maturity in the sense that there's no possibility to plug in multiple formulas that interact with each other... yet.
    juju deploy of openstack
    • Mitch Michell from Hashicorp presented vault. Vault stores your secrets (certificates, passwords, etc.) and we will probably be trying it out in the near future. A lot of concepts in vault are really well thought out and resonate with some of the things we want to do and automate in our infrastructure. The use of Shamir Secret Sharing technique (also used in the debian infrastructure team) for the N-man challenge to unvault the secrets is quite nice. David is already looking into automating it with Salt and having GSSAPI (kerberos) authentication. bikes!

    Day 2

    • Gareth Rushgrove from PuppetLabs talked about the importance of metadata in docker images and docker containers by explaining how these greatly benefit tools like dpkg and rpm and that the container community should be inspired by the amazing skills and experience that has been built by these package management communities (think of all the language-specific package managers that each reinvent the wheel one after the other).
    • Testing Immutable Infrastructure: we found some inspiration from test-kitchen and running the tests inside a docker container instead of vagrant virtual machine. We'll have to take a look at the SaltStack provisioner for test-kitchen. We already do some of that stuff in docker and OpenStack using salt-cloud. But maybe we can take it further with such tools (or testinfra whose author will be joining Logilab next month).
    coreos, rkt, kubernetes
    • How CoreOS is built, modified, and updated: From repo sync to Omaha by Brian "RedBeard" Harrington. Interesting presentation of the CoreOS system. Brian also revealed that CoreOS is now capable of using the TPM to enforce a signed OS, but also signed containers. Official CoreOS images shipped through Omaha are now signed with a root key that can be installed in the TPM of the host (ie. they didn't use a pre-installed Microsoft key), along with a modified TPM-aware version of GRUB. For now, the Omaha platform is not open source, so it may not be that easy to build one's own CoreOS images signed with a personal root key, but it is theoretically possible. Brian also said that he expect their Omaha server implementation to become open source some day.
    • The use of Salt in Foreman was presented and demoed by Stephen Benjamin. We'll have to retry using that tool with the newest features of the smart proxy.
    • Jonathan Boulle from CoreOS presented "rkt and Kubernetes: What’s new with Container Runtimes and Orchestration" In this last talk, Johnathan gave a tour of the rkt project and how it is used to build, coupled with kubernetes, a comprehensive, secure container running infrastructure (which uses saltstack!). He named the result "rktnetes". The idea is to use rkt as the kubelet's (primany node agent) container runtime of a kubernetes cluster powered by CoreOS. Along with the new CoreOS support for TPM-based trust chain, it allows to ensure completely secured executions, from the bootloader to the container! The possibility to run fully secured containers is one of the reasons why CoreOS developed the rkt project.

    We would like to thank the cfgmgmntcamp organisation team, it was a great conference, we highly recommend it. Thanks for the speaker event the night before the conference, and the social event on Monday evening. (and thanks for the chocolate!).

  • We went to FOSDEM 2016 (and cfgmgmtcamp)

    2016/02/09 by Arthur Lutz

    David & I went to FOSDEM and cfgmgmtcamp this year to see some conferences, do two presentations, and discuss with the members of the open source communities we contribute to.

    At FOSDEM, we started early by doing a presentation at 9.00 am in the "Configuration Management devroom", which to our surprise was a large room which was almost full. The presentation was streamed over the Internet and should be available to view shortly.

    I presented "Once you've configured your infrastructure using salt, monitor it by re-using that definition". (mirrored on slideshare. The main part was a demo, the code being published on bitbucket.

    The presentation was streamed live (I came across someone that watched it on the Internet to "sleep in"), and should be available to watch when it gets encoded on

    FOSDEM video box

    We then saw the following talks :

    • Unified Framework for Big Data Foreign Data Wrappers (FDW) by Shivram Mani in the Postgresql Track
    • Mainflux Open Source IoT Cloud
    • EzBench, a tool to help you benchmark and bisect the Graphics Stack's performance
    • The RTC components in the debian infrastructure
    • CoreOS: A Linux distribution designed for application containers that scale
    • Using PostgreSQL for Bibliographic Data (since we've worked on with and PostgreSQL)
    • The FOSDEM infrastructure review

    Congratulations to all the FOSDEM organisers, volunteers and speakers. We will hopefully be back for more.

    We then took the train to Gent where we spent two days learning and sharing about Configuration Management Systems and all the ecosystem around it (orchestration, containers, clouds, testing, etc.).

    More on our cfmgmtcamp experience in another blog post.

    Photos under creative commons CC-BY, by Ludovic Hirlimann and Deborah Bryant here and here

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

    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.

    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.

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

    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$$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, 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 ,, 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


    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.


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

    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.

    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.

  • Tisséo, bon élève de l'Open Data

    2015/11/12 by Sylvain Thenault

    J'ai assisté mardi dernier à un "6 à 8" à la Cantine de Toulouse, sur le thème de l'Open-Data chez Tisséo, opérateur des transports en commun du coin.

    (photo par Cc By SA Guillaume Paumier licence CC-By-SA)

    Sandrine Mathon, pour le compte de Toulouse Métropole, nous a présenté Cyril Boitel, responsable données "statiques" et Xavier Raffin, responsable de l'infrastructure et de l'API pour l'accès au données "temps réels". Cyril et Xavier nous ont fait une rapide présentation avant de passer à l'essence de ce type d'évènement : le buffet ! Hormis les petits fours, voici quelques points que j'ai retenu...

    Tisséo est associé à la démarche d'ouverture des données à Toulouse depuis l'origine ou presque, soit depuis 4 ans. Elle publie aujourd'hui une API d'accès aux données temps réel, deux fichiers horaires statiques (GTFS, NEPTUNE/ Trident), 3 fichiers cartographiques (métro, tram, bus), et répond à environ 8 millions de requêtes par mois. Les données sont sous licences ODBL.

    L'accès à l'API est conditionné par l'obtention d'une clé, sur simple demande. Non pas pour juger de votre projet et encore moins de qui la demande, mais simplement pour établir un contact avec l'équipe et permettre ensuite à Tisséo de faire quelques statistiques. Et cela permet au pire de bloquer l'accès à une clé en cas d'usage abusif de l'API, mais ils ont plus souvent affaire à des accidents que des vraies tentatives d'attaque de type DOS. Dans ces cas là, l'équipe prend contact pour signaler le problème avant de recourir au blocage de la clé. Depuis l'ouverture du service, un peu plus de 200 clés ont été délivrées (attention, certaines sont utilisées par des promos entières d'étudiants !).

    Leurs statistiques, outre un volume en progression constante, montrent que l'essentiel des requêtes est généré par les systèmes de complétion, qui génèrent une nouvelle requête dès qu'un petit caractère change. Les trucs plus compliqués comme le calcul d'itinéraire ne représentent que quelques pourcents du total. J'ai d'ailleurs appris à ce sujet l'existence (j'avoue ne m'être jamais posé la question) de plusieurs calculateurs d'itinéraire Open-Source :, OpenTripPlanner ou encore SYNTHESE. Apparemment chez Tisséo ils ont un peu goûté à tout, mais ils sont en train de migrer vers, qui possède quelques belles références.

    Je finirais par les deux points qui me font penser au côté "bon élève" de l'Open-Data : d'abord cette démarche, qui n'a pas fait que des heureux en interne et représente un coût, a permis d'une part une amélioration de la qualité des données qu'ils avaient eux même à disposition, et d'autre part une rationalisation de l'infrastructure, car leur application mobile est branchée sur la même API que celle mise à disposition du public. En prime, ce dernier point motive évidemment à avoir tout en ordre de marche et aide à trouver les bugs avant les autres. Tous les avantages du eat your own dog food quoi ! Enfin, Tisséo est engagé dans un groupe de réflexion autour de l'Open-Transport qui inclut, entre autres poids lourds du secteur, la SNCF afin de tenter de normaliser un peu tout ça.

    Ces deux points sont de mon point de vue deux facteurs clés de l'Open-data et ne sont pas encore mis assez en avant. Ça aura donc été une occasion de l'entendre et de le redire, merci à Sandrine, Cyril et Xavier !

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

    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 !

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


    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) :

    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.

    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.

    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.


    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.


    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

    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.

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

    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.

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

    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 :

    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.

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

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

    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.

    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"

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

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

    (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é.

  • DebConf15 wrap-up

    2015/08/25 by Julien Cristau

    I just came back from two weeks in Heidelberg for DebCamp15 and DebConf15.

    In the first week, besides helping out DebConf's infrastructure team with network setup, I tried to make some progress on the library transitions triggered by libstdc++6's C++11 changes. At first, I spent many hours going through header files for a bunch of libraries trying to figure out if the public API involved std::string or std::list. It turns out that is time-consuming, error-prone, and pretty efficient at making me lose the will to live. So I ended up stealing a script from Steve Langasek to automatically rename library packages for this transition. This ended in 29 non-maintainer uploads to the NEW queue, quickly processed by the FTP team. Sadly the transition is not quite there yet, as making progress with the initial set of packages reveals more libraries that need renaming.

    Building on some earlier work from Laurent Bigonville, I've also moved the setuid root Xorg wrapper from the xserver-xorg package to xserver-xorg-legacy, which is now in experimental. Hopefully that will make its way to sid and stretch soon (need to figure out what to do with non-KMS drivers first).

    Finally, with the help of the security team, the security tracker was moved to a new VM that will hopefully not eat its root filesystem every week as the old one was doing the last few months. Of course, the evening we chose to do this was the night DebConf15's network was being overhauled, which made things more interesting.

    DebConf itself was the opportunity to meet a lot of people. I was particularly happy to meet Andreas Boll, who has been a member of pkg-xorg for two years now, working on our mesa package, among other things. I didn't get to see a lot of talks (too many other things going on), but did enjoy Enrico's stand up comedy, the CitizenFour screening, and Jake Applebaum's keynote. Thankfully, for the rest the video team has done a great job as usual.


    Above picture is by Aigars Mahinovs, licensed under CC-BY 2.0

  • Going to DebConf15

    2015/08/11 by Julien Cristau

    On Sunday I travelled to Heidelberg, Germany, to attend the 16th annual Debian developer's conference, DebConf15.

    The conference itself is not until next week, but this week is DebCamp, a hacking session. I've already met a few of my DSA colleagues, who've been working on setting up the network infrastructure. My other plans for this week involve helping the Big Transition of 2015 along, and trying to remove the setuid bit from /usr/bin/X in the default Debian install (bug #748203 in particular).

    As for next week, there's a rich schedule in which I'll need to pick a few things to go see.


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

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

  • Experiments on building a Jenkins CI service with Salt

    2015/06/17 by Denis Laxalde

    In this blog post, I'll talk about my recent experiments on building a continuous integration service with Jenkins that is, as much as possible, managed through Salt. We've been relying on a Jenkins platform for quite some time at Logilab (Tolosa team). The service was mostly managed by me with sporadic help from other team-mates but I've never been entirely satisfied about the way it was managed because it involved a lot of boilerplate configuration through Jenkins user interface and this does not scale very well nor does it make long term maintenance easy.

    So recently, I've taken a stance and decided to go through a Salt-based configuration and management of our Jenkins CI platform. There are actually two aspects here. The first concerns the setup of Jenkins itself (this includes installation, security configuration, plugins management amongst other things). The second concerns the management of client projects (or jobs in Jenkins jargon). For this second aspect, one of the design goals was to enable easy configuration of jobs by users not necessarily familiar with Jenkins setup and to make collaborative maintenance easy. To tackle these two aspects I've essentially been using (or developing) two distinct Salt formulas which I'll detail hereafter.

    Jenkins jobs salt

    Core setup: the jenkins formula

    The core setup of Jenkins is based on an existing Salt formula, the jenkins-formula which I extended a bit to support map.jinja and which was further improved to support installation of plugins by Yann and Laura (see 3b524d4).

    With that, deploying a Jenkins server is as simple as adding the following to your states and pillars top.sls files:

        - jenkins
        - jenkins.plugins

    Base pillar configuration is used to declare anything that differs from the default Jenkins settings in a jenkins section, e.g.:

        - home: /opt/jenkins

    Plugins configuration is declared in plugins subsection as follows:

            url: ''
            hash: 'md5=9574c07bf6bfd02a57b451145c870f0e'
            url: ''
            hash: 'md5=1b46e2732be31b078001bcc548149fe5'

    (Note that plugins dependency is not handled by Jenkins when installing from the command line, neither by this formula. So in the preceding example, just having an entry for the Mercurial plugin would have not been enough because this plugin depends on scm-api.)

    Other aspects (such as security setup) are not handled yet (neither by the original formula, nor by our extension), but I tend to believe that this is acceptable to manage this "by hand" for now.

    Jobs management : the jenkins_jobs formula

    For this task, I leveraged the excellent jenkins-job-builder tool which makes it possible to configure jobs using a declarative YAML syntax. The tool takes care of installing the job and also handles any housekeeping tasks such as checking configuration validity or deleting old configurations. With this tool, my goal was to let end-users of the Jenkins service add their own project by providing a minima a YAML job description file. So for instance, a simple Job description for a CubicWeb job could be:

    - scm:
        name: cubicweb
          - hg:
             clean: true
    - job:
        name: cubicweb
        display-name: CubicWeb
          - cubicweb
          - shell: "find . -name 'tmpdb*' -delete"
          - shell: "tox --hashseed noset"
          - email:

    It consists of two parts:

    • the scm section declares, well, SCM information, here the location of the review Mercurial repository, and,

    • a job section which consists of some metadata (project name), a reference of the SCM section declared above, some builders (here simple shell builders) and a publisher part to send results by email.

    Pretty simple. (Note that most test running configuration is here declared within the source repository, via tox (another story), so that the CI bot holds minimum knowledge and fetches information from the sources repository directly.)

    To automate the deployment of this kind of configurations, I made a jenkins_jobs-formula which takes care of:

    1. installing jenkins-job-builder,
    2. deploying YAML configurations,
    3. running jenkins-jobs update to push jobs into the Jenkins instance.

    In addition to installing the YAML file and triggering a jenkins-jobs update run upon changes of job files, the formula allows for job to list distribution packages that it would require for building.

    Wrapping things up, a pillar declaration of a Jenkins job looks like:

            file: <path to local cubicweb.yaml>
              - mercurial
              - python-dev
              - libgecode-dev

    where the file section indicates the source of the YAML file to install and pkgs lists build dependencies that are not managed by the job itself (typically non Python package in our case).

    So, as an end user, all is needed to provide is the YAML file and a pillar snippet similar to the above.


    This initial setup appears to be enough to greatly reduce the burden of managing a Jenkins server and to allow individual users to contribute jobs for their project based on simple contribution to a Salt configuration.

    Later on, there is a few things I'd like to extend on jenkins_jobs-formula side. Most notably the handling of distant sources for YAML configuration file (as well as maybe the packages list file). I'd also like to experiment on configuring slaves for the Jenkins server, possibly relying on Docker (taking advantage of another of my experiment...).

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

    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 ;

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


    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.



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


    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.


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

  • Running a local salt-master to orchestrate docker containers

    2015/05/20 by David Douard

    In a recent blog post, Denis explained how to build Docker containers using Salt.

    What's missing there is how to have a running salt-master dedicated to Docker containers.

    There is not need the salt-master run as root for this. A test config of mine looks like:

    david@perseus:~$ mkdir -p salt/etc/salt
    david@perseus:~$ cd salt
    david@perseus:~salt/$ cat << EOF >etc/salt/master
    user: david
    root_dir: /home/david/salt/
    pidfile: var/run/
    pki_dir: etc/salt/pki/master
    cachedir: var/cache/salt/master
    sock_dir: var/run/salt/master
        - /home/david/salt/states
        - /home/david/salt/formulas/cubicweb
        - /home/david/salt/pillar

    Here, is the ip of my docker0 bridge. Also note that path in file_roots and pillar_roots configs must be absolute (they are not relative to root_dir, see the salt-master configuration documentation).

    Now we can start a salt-master that will be accessible to Docker containers:

    david@perseus:~salt/$ /usr/bin/salt-master -c etc/salt


    with salt 2015.5.0, salt-master really wants to execute dmidecode, so add /usr/sbin to the $PATH variable before running the salt-master as non-root user.

    From there, you can talk to your test salt master by adding -c ~/salt/etc/salt option to all salt commands. Fortunately, you can also set the SALT_CONFIG_DIR environment variable:

    david@perseus:~salt/$ export SALT_CONFIG_DIR=~/salt/etc/salt
    david@perseus:~salt/$ salt-key
    Accepted Keys:
    Denied Keys:
    Unaccepted Keys:
    Rejected Keys:

    Now, you need to have a Docker images with salt-minion already installed, as explained in Denis' blog post. (I prefer using supervisord as PID 1 in my dockers, but that's not important here.)

    david@perseus:~salt/ docker run -d --add-host salt:  logilab/salted_debian:wheezy
    david@perseus:~salt/ docker run -d --name jessie1 --hostname jessie1 --add-host salt:  logilab/salted_debian:jessie
    david@perseus:~salt/ salt-key
    Accepted Keys:
    Denied Keys:
    Unaccepted Keys:
    Rejected Keys:
    david@perseus:~/salt$ salt-key -y -a 53bf7d8db530
    The following keys are going to be accepted:
    Unaccepted Keys:
    Key for minion 53bf7d8db530 accepted.
    david@perseus:~/salt$ salt-key -y -a jessie1
    The following keys are going to be accepted:
    Unaccepted Keys:
    Key for minion jessie1 accepted.
    david@perseus:~/salt$ salt '*'

    You can now build Docker images as explained by Denis, or test your sls config files in containers.

  • Mini-Debconf Lyon 2015

    2015/04/29 by Julien Cristau

    A couple of weeks ago I attended the mini-DebConf organized by Debian France in Lyon.

    It was a really nice week-end, and the first time a French mini-DebConf wasn't in Paris :)

    Among the highlights, Juliette Belin reported on her experience as a new contributor to Debian: she authored the awesome "Lines" theme which was selected as the default theme for Debian 8.


    As a non-developer and newcomer to the free software community, she had quite intesting insights and ideas about areas where development processes need to improve.

    And Raphael Geissert reported on the new service (previously, an http redirector to automagically pick the closest Debian archive mirror. So long, manual sources.list updates on laptops whenever travelling!


    Finally the mini-DebConf was a nice opportunity to celebrate the release of Debian 8, two weeks in advance.

    Now it's time to go and upgrade all our infrastructure to jessie.

  • Building Docker containers using Salt

    2015/04/07 by Denis Laxalde

    In this blog post, I'll talk about a way to use Salt to automate the build and configuration of Docker containers. I will not consider the deployment of Docker containers with Salt as this subject is already covered elsewhere (here for instance). The emphasis here is really on building (or configuring) a container for future deployment.


    Salt is a remote execution framework that can be used for configuration management. It's already widely used at Logilab to manage our infrastructure as well as on a semi-daily basis during our application development activities.

    Docker is a tool that helps automating the deployment of applications within Linux containers. It essentially provides a convenient abstraction and a set of utilities for system level virtualization on Linux. Amongst other things, Docker provides container build helpers around the concept of dockerfile.

    So, the first question is why would you use Salt to build Docker containers when you already have this dockerfile building tool. My first motivation is to encompass the limitations of the available declarations one could insert in a Dockerfile. First limitation: you can only execute instructions in a sequential manner using a Dockerfile, there's is no possibility of declaring dependencies between instructions or even of making an instruction conditional (apart from using the underlying shell conditional machinery of course). Then, you have only limited possibilities of specializing a Dockerfile. Finally, it's no so easy to apply a configuration step-by-step, for instance during the development of said configuration.

    That's enough for an introduction to lay down the underlying motivation of this post. Let's move on to more practical things!

    A Dockerfile for the base image

    Before jumping into the usage of Salt for the configuration of a Docker image, the first thing you need to do is to build a Docker container into a proper Salt minion.

    Assuming we're building on top of some a base image of Debian flavour subsequently referred to as <debian> (I won't tell you where it comes from, since you ought to build your own base image -- or find some friend you trust to provide you with one!), the following Dockerfile can be used to initialize a working image which will serve as the starting point for further configuration with Salt:

    FROM <debian>
    RUN apt-get update
    RUN apt-get install -y salt-minion

    Then, run docker build . docker_salt/debian_salt_minion and you're done.

    Plugin the minion container with the Salt master

    The next thing to do with our fresh Debian+salt-minion image is to turn it into a container running salt-minion, waiting for the Salt master to instruct it.

    docker run --add-host=salt: --hostname docker_minion \
        --name minion_container \
        docker_salt/debian/salt_minion salt-minion


    • --hostname is used to specify the network name of the container, for easier query by the Salt master,
    • is usually the IP address of the host, which in our example will serve as the Salt master,
    • --name is just used for easier book-keeping.


    salt-key -a docker_minion

    will register the new minion's key into the master's keyring.

    If all went well, the following command should succeed:

    salt 'docker_minion'

    Configuring the container with a Salt formula

    salt 'docker_minion' state.sls some_formula
    salt 'docker_minion' state.highstate

    Final steps: save the configured image and build a runnable image

    (Optional step, cleanup salt-minion installation.)

    Make a snapshot image of your configured container.

    docker stop minion_container
    docker commit -m 'Install something with Salt' \
        minion_container me/something

    Try out your new image:

    docker run -p 8080:80 me/something <entry point>

    where <entry point> will be the main program driving the service provided by the container (typically defined through the Salt formula).

    Make a fully configured image for you service:

    FROM me/something
    [...anything else you need, such as EXPOSE, etc...]
    CMD <entry point>

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

    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.

  • Monitoring our websites before we deploy them using Salt

    2015/03/11 by Arthur Lutz

    As you might have noticed we're quite big fans of Salt. One of the things that Salt enables us to do, it to apply what we're used to doing with code to our infrastructure. Let's look at TDD (Test Driven Development).

    Write the test first, make it fail, implement the code, test goes green, you're done.

    Apply the same thing to infrastructure and you get TDI (Test Driven Infrastructure).

    So before you deploy a service, you make sure that your supervision (shinken, nagios, incinga, salt based monitoring, etc.) is doing the correct test, you deploy and then your supervision goes green.

    Let's take a look at website supervision. At Logilab we weren't too satisfied with how our shinken/http_check were working so we started using uptime (nodejs + mongodb). Uptime has a simple REST API to get and add checks, so we wrote a salt execution module and a states module for it.

    For the sites that use the apache-formula we simply loop on the domains declared in the pillars to add checks :

    {% for domain in salt['pillar.get']('apache:sites').keys() %}
    uptime {{ domain }} (http):
        - name : http://{{ domain }}
    {% endfor %}

    For other URLs (specific URL such as sitemaps) we can list them in pillars and do :

    {% for url in salt['pillar.get']('uptime:urls') %}
    uptime {{ url }}:
        - name : {{ url }}
    {% endfor %}

    That's it. Monitoring comes before deployment.

    We've also contributed a formula for deploying uptime.

    Follow us if you are interested in Test Driven Infrastructure for we intend to write regular reports as we make progress exploring this new domain.

  • A report on the Salt Sprint 2015 in Paris

    2015/03/05 by Arthur Lutz

    On Wednesday the 4th of march 2015, Logilab hosted a sprint on salt on the same day as the sprint at SaltConf15. 7 people joined in and hacked on salt for a few hours. We collaboratively chose some subjects on a pad which is still available.


    We started off by familiarising those who had never used them to using tests in salt. Some of us tried to run the tests via tox which didn't work any more, a fix was found and will be submitted to the project.

    We organised in teams.

    Boris & Julien looked at the authorisation code and wrote a few issues (minion enumeration, acl documentation). On saltpad (client side) they modified the targeting to adapt to the permissions that the salt-api sends back.

    We discussed the salt permission model (external_auth) : where should the filter happen ? the master ? should the minion receive information about authorisation and not execute what is being asked for ? Boris will summarise some of the discussion about authorisations in a new issue.


    Sofian worked on some unification on execution modules (refresh_db which will be ignored for the modules that don't understand that). He will submit a pull request in the next few days.

    Georges & Paul added some tests to hg_pillar, the test creates a mercurial repository, adds a top.sls and a file and checks that they are visible. Here is the diff. They had some problems while debugging the tests.

    David & Arthur implemented the execution module for managing postgresql clusters (create, list, exists, remove) in debian. A pull request was submitted by the end of the day. A state module should follow shortly. On the way we removed some dead code in the postgres module.

    All in all, we had some interesting discussions about salt, it's architecture, shared tips about developing and using it and managed to get some code done. Thanks to all for participating and hopefully we'll sprint again soon...

  • Generate stats from your SaltStack infrastructure

    2014/12/15 by Arthur Lutz

    As presented at the November french meetup of saltstack users, we've published code to generate some statistics about a salstack infrastructure. We're using it, for the moment, to identify which parts of our infrastructure need attention. One of the tools we're using to monitor this distance is munin.

    You can grab the code at bitbucket salt-highstate-stats, fork it, post issues, discuss it on the mailing lists.

    If you're french speaking, you can also read the slides of the above presentation (mirrored on slideshare).

    Hope you find it useful.

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

    2014/11/04 by Arthur Lutz

    Suite à :


    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 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 :

    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 :

    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.

    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 :

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

    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 :

    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.

    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.

    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 :

    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

    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 :

  • PyconFR 2014 - on y va !

    2014/10/24 by Arthur Lutz 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.

    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.

  • Using Saltstack to limit impact of Poodle SSLv3 vulnerability

    2014/10/15 by Arthur Lutz

    Here at Logilab, we're big fans of SaltStack automation. As seen with Heartbleed, controlling your infrastructure and being able to fix your servers in a matter of a few commands as documented in this blog post. Same applies to Shellshock more recently with this blog post.

    Yesterday we got the news that a big vulnerability on SSL was going to be released. Code name : Poodle. This morning we got the details and started working on a fix through salt.

    So far, we've handled configuration changes and services restart for apache, nginx, postfix and user configuration for iceweasel (debian's firefox) and chromium (adapting to firefox and chrome should be a breeze). Some credit goes to mtpettyp for his answer on askubuntu.
    {% if salt['pkg.version']('apache2') %}
    poodle apache server restart:
            - name: apache2
      {% for foundfile in salt['']('rgrep -m 1 SSLProtocol /etc/apache*').split('\n') %}
        {% if 'No such file' not in foundfile and 'bak' not in foundfile and foundfile.strip() != ''%}
    poodle {{ foundfile.split(':')[0] }}:
            - name : {{ foundfile.split(':')[0] }}
            - pattern: "SSLProtocol all -SSLv2[ ]*$"
            - repl: "SSLProtocol all -SSLv2 -SSLv3"
            - backup: False
            - show_changes: True
            - watch_in:
                service: apache2
        {% endif %}
      {% endfor %}
    {% endif %}
    {% if salt['pkg.version']('nginx') %}
    poodle nginx server restart:
            - name: nginx
      {% for foundfile in salt['']('rgrep -m 1 ssl_protocols /etc/nginx/*').split('\n') %}
        {% if 'No such file' not in foundfile and 'bak' not in foundfile and foundfile.strip() != ''%}
    poodle {{ foundfile.split(':')[0] }}:
            - name : {{ foundfile.split(':')[0] }}
            - pattern: "ssl_protocols .*$"
            - repl: "ssl_protocols TLSv1 TLSv1.1 TLSv1.2;"
            - show_changes: True
            - watch_in:
                service: nginx
        {% endif %}
      {% endfor %}
    {% endif %}
    {% if salt['pkg.version']('postfix') %}
    poodle postfix server restart:
            - name: postfix
    poodle /etc/postfix/
    {% if '' in salt['']('grep smtpd_tls_mandatory_protocols /etc/postfix/') %}
            - pattern: "smtpd_tls_mandatory_protocols=.*"
            - repl: "smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3"
    {% else %}
            - text: |
                # poodle fix
    {% endif %}
            - name: /etc/postfix/
            - watch_in:
                service: postfix
    {% endif %}
    {% if salt['pkg.version']('chromium') %}
            - pattern: Exec=/usr/bin/chromium %U
            - repl: Exec=/usr/bin/chromium --ssl-version-min=tls1 %U
    {% endif %}
    {% if salt['pkg.version']('iceweasel') %}
            - text : pref("security.tls.version.min", "1")
    {% endif %}

    The code is also published as a gist on github. Feel free to comment and fork the gist. There is room for improvement, and don't forget that by disabling SSLv3 you might prevent some users with "legacy" browsers from accessing your services.

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

    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.

    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 :

    À 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 :

    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.

  • Report from DebConf14

    2014/09/05 by Julien Cristau

    Last week I attended DebConf14 in Portland, Oregon. As usual the conference was a blur, with lots of talks, lots of new people, and lots of old friends. The organizers tried to do something different this year, with a longer conference (9 days instead of a week) and some dedicated hack time, instead of a pre-DebConf "DebCamp" week. That worked quite well for me, as it meant the schedule was not quite so full with talks, and even though I didn't really get any hacking done, it felt a bit more relaxed and allowed some more hallway track discussions.

    On the talks side, the keynotes from Zack and Biella provided some interesting thoughts. Some nice progress was made on making package builds reproducible.

    I gave two talks: an introduction to salt (odp),

    and a report on the Debian jessie release progress (pdf).

    And as usual all talks were streamed live and recorded, and many are already available thanks to the awesome DebConf video team. Also for a change, and because I'm a sucker for punishment, I came back with more stuff to do.

  • Logilab à EuroSciPy 2014

    2014/09/02 by Florent Cayré

    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.


    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.


    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.

  • Logilab at Debconf 2014 - Debian annual conference

    2014/08/21 by Arthur Lutz

    Logilab is proud to contribute to the annual debian conference which will take place in Portland (USA) from the 23rd to the 31st of august.

    Julien Cristau (debian page) will be giving two talks at the conference :

    Logilab is also contributing to the conference as a sponsor for the event.

    Here is what we previously blogged about salt and the previous debconf . Stay tuned for a blog post about what we saw and heard at the conference.

  • Pylint 1.3 / Astroid 1.2 released

    2014/07/28 by Sylvain Thenault

    The EP14 Pylint sprint team (more on this here and there) is proud to announce they just released Pylint 1.3 together with its companion Astroid 1.2. As usual, this includes several new features as well and bug fixes. You'll find below some structured list of the changes.

    Packages are uploaded to pypi, debian/ubuntu packages should be soon provided by Logilab, until they get into the standard packaging system of your favorite distribution.

    Please notice Pylint 1.3 will be the last release branch support python 2.5 and 2.6. Starting from 1.4, we will only support python greater or equal to 2.7. This will be the occasion to do some great cleanup in the code base. Notice this is only about the Pylint's runtime, you should still be able to run Pylint on your Python 2.5 code, through using Python 2.7 at least.

    New checks

    • Add multiple checks for PEP 3101 advanced string formatting: 'bad-format-string', 'missing-format-argument-key', 'unused-format-string-argument', 'format-combined-specification', 'missing-format-attribute' and 'invalid-format-index'
    • New 'invalid-slice-index' and 'invalid-sequence-index' for invalid sequence and slice indices
    • New 'assigning-non-slot' warning, which detects assignments to attributes not defined in slots

    Improved checkers

    • Fixed 'fixme' false positive (#149)
    • Fixed 'unbalanced-iterable-unpacking' false positive when encountering starred nodes (#273)
    • Fixed 'bad-format-character' false positive when encountering the 'a' format on Python 3
    • Fixed 'unused-variable' false positive when the variable is assigned through an import (#196)
    • Fixed 'unused-variable' false positive when assigning to a nonlocal (#275)
    • Fixed 'pointless-string-statement' false positive for attribute docstrings (#193)
    • Emit 'undefined-variable' when using the Python 3 metaclass= argument. Also fix 'unused-import' false for that construction (#143)
    • Emit 'broad-except' and 'bare-except' even if the number of except handlers is different than 1. Fixes issue (#113)
    • Emit 'attribute-defined-outside-init' for all statements in the same module as the offended class, not just for the last assignment (#262, as well as a long standing output mangling problem in some edge cases)
    • Emit 'not-callable' when calling properties (#268)
    • Don't let ImportError propagate from the imports checker, leading to crash in some namespace package related cases (#203)
    • Don't emit 'no-name-in-module' for ignored modules (#223)
    • Don't emit 'unnecessary-lambda' if the body of the lambda call contains call chaining (#243)
    • Definition order is considered for classes, function arguments and annotations (#257)
    • Only emit 'attribute-defined-outside-init' for definition within the same module as the offended class, avoiding to mangle the output in some cases
    • Don't emit 'hidden-method' message when the attribute has been monkey-patched, you're on your own when you do that.

    Others changes

    • Checkers are now properly ordered to respect priority(#229)
    • Use the proper mode for pickle when opening and writing the stats file (#148)

    Astroid changes

    • Function nodes can detect decorator call chain and see if they are decorated with builtin descriptors (classmethod and staticmethod).
    • infer_call_result called on a subtype of the builtin type will now return a new Class rather than an Instance.
    • Class.metaclass() now handles module-level __metaclass__ declaration on python 2, and no longer looks at the __metaclass__ class attribute on python 3.
    • Add slots method to Class nodes, for retrieving the list of valid slots it defines.
    • Expose function annotation to astroid: Arguments node exposes 'varargannotation', 'kwargannotation' and 'annotations' attributes, while Function node has the 'returns' attribute.
    • Backported most of the logilab.common.modutils module there, as most things there are for pylint/astroid only and we want to be able to fix them without requiring a new logilab.common release
    • Fix names grabed using wildcard import in "absolute import mode" (i.e. with absolute_import activated from the __future__ or with python 3) (pylint issue #58)
    • Add support in brain for understanding enum classes.

  • EP14 Pylint sprint Day 2 and 3 reports

    2014/07/28 by Sylvain Thenault

    Here are the list of things we managed to achieve during those last two days at EuroPython.

    After several attempts, Michal managed to have pylint running analysis on several files in parallel. This is still in a pull request ( because of some limitations, so we decided it won't be part of the 1.3 release.

    Claudiu killed maybe 10 bugs or so and did some heavy issues cleanup in the trackers. He also demonstrated some experimental support of python 3 style annotation to drive a better inference. Pretty exciting! Torsten also killed several bugs, restored python 2.5 compat (though that will need a logilab-common release as well), introduced a new functional test framework that will replace the old one once all the existing tests will be backported. On wednesday, he did show us a near future feature they already have at Google: some kind of confidence level associated to messages so that you can filter out based on that. Sylvain fixed a couple of bugs (including which was annoying all the numpy community), started some refactoring of the PyLinter class so it does a little bit fewer things (still way too many though) and attempted to improve the pylint note on both pylint and astroid, which went down recently "thanks" to the new checks like 'bad-continuation'.

    Also, we merged the pylint-brain project into astroid to simplify things, so you should now submit your brain plugins directly to the astroid project. Hopefuly you'll be redirected there on attempt to use the old (removed) pylint-brain project on bitbucket.

    And, the good news is that now both Torsten and Claudiu have new powers: they should be able to do some releases of pylint and astroid. To celebrate that and the end of the sprint, we published Pylint 1.3 together with Astroid 1.2. More on this here.

  • EP14 Pylint sprint Day 1 report

    2014/07/24 by Sylvain Thenault

    We've had a fairly enjoyable and productive first day in our little hidden room at EuroPython in Berlin ! Below are some noticeable things we've worked on and discussed about.

    First, we discussed and agreed that while we should at some point cut the cord to the logilab.common package, it will take some time notably because of the usage logilab.common.configuration which would be somewhat costly to replace (and is working pretty well). There are some small steps we should do but basically we should mostly get back some pylint/astroid specific things from logilab.common to astroid or pylint. This should be partly done during the sprint, and remaining work will go to tickets in the tracker.

    We also discussed about release management. The point is that we should release more often, so every pylint maintainers should be able to do that easily. Sylvain will write some document about the release procedure and ensure access are granted to the pylint and astroid projects on pypi. We shall release pylint 1.3 / astroid 1.2 soon, and those releases branches will be the last one supporting python < 2.7.

    During this first day, we also had the opportunity to meet Carl Crowder, the guy behind, as well as David Halter which is building the Jedi completion library ( runs pylint on thousands of projects, and it would be nice if we could test beta release on some part of this panel. On the other hand, there are probably many code to share with the Jedi library like the parser and ast generation, as well as a static inference engine. That deserves a sprint on his own though, so we agreed that a nice first step would be to build a common library for import resolution without relying on the python interpreter for that, while handling most of the python dark import features like zip/egg import, .pth files and so one. Indeed that may be two nice future collaborations!

    Last but not least, we got some actual work done:

    • Michal Nowikowski from Intel in Poland joined us to work on the ability to run pylint in different processes so it may drastically improve performance on multiple cores box.
    • Torsten did continue some work on various improvements of the functionnal test framework.
    • Sylvain did merge logilab.common.modutils module into astroid as it's mostly driven by astroid and pylint needs. Also fixed the annoying namespace package crash.
    • Claudiu keep up the good work he does daily at improving and fixing pylint :)

  • PyLint sprint during EuroPython in Berlin

    2014/07/11 by Sylvain Thenault

    The three main maintainers/developpers of Pylint/astroid (Claudiu, Torsten and I) will meet together in Berlin during EuroPython 2014. While this is not an "official" EuroPython sprint but it's still worth announcing it since it's a good opportunity to meet and enhance Pylint. We should find place and time to work on Pylint between wednesday 23 and friday 25.

    If you're interested, don't hesitate to contact me ( / @sythenault).

  • Nazca notebooks

    2014/07/04 by Vincent Michel

    We have just published the following ipython notebooks explaining how to perform record linkage and entities matching with Nazca:

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

    2014/06/20 by Damien Garaud


    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


    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.


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


    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;


    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
      return 0;


    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

    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

    J'utiliserai la deuxième solution.


    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.

    #include <boost/test/unit_test.hpp>
    #include <boost/mpi/environment.hpp>
    #include <boost/mpi/communicator.hpp>
    namespace mpi = boost::mpi;
        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}

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

  • Open Legislative Data Conference 2014

    2014/06/10 by Nicolas Chauvat

    I was at the Open Legislative Data Conference on may 28 2014 in Paris, to present a simple demo I worked on since the same event that happened two years ago.

    The demo was called "Law is Code Rebooted with CubicWeb". It featured the use of the cubicweb-vcreview component to display the amendments of the hospital law ("loi hospitalière") gathered into a version control system (namely Mercurial).

    The basic idea is to compare writing code and writing law, for both are collaborative and distributed writing processes. Could we reuse for the second one the tools developed for the first?

    Here are the slides and a few screenshots.

    Statistics with queries embedded in report page.

    List of amendments.

    User comment on an amendment.

    While attending the conference, I enjoyed several interesting talks and chats with other participants, including:

    1. the study of co-sponsorship of proposals in the french parliament
    2. announcing their use of PostgreSQL and JSON.
    3. and last but not least, the great work done by RegardsCitoyens and SciencesPo MediaLab on visualizing the law making process.

    Thanks to the organisation team and the other speakers. Hope to see you again!

  • SaltStack Meetup with Thomas Hatch in Paris France

    2014/05/22 by Arthur Lutz

    This monday (19th of may 2014), Thomas Hatch was in Paris for dotScale 2014. After presenting SaltStack there (videos will be published at some point), he spent the evening with members of the French SaltStack community during a meetup set up by Logilab at IRILL.

    Here is a list of what we talked about :

    • Since Salt seems to have pushed ZMQ to its limits, SaltStack has been working on RAET (Reliable Asynchronous Event Transport Protocol ), a transport layer based on UDP and elliptic curve cryptography (Dan Berstein's CURVE-255-19) that works more like a stack than a socket and has reliability built in. RAET will be released as an optionnal beta feature in the next Salt release.
    • Folks from Dailymotion bumped into a bug that seems related to high latency networks and the auth_timeout. Updating to the very latest release should fix the issue.
    • Thomas told us about how a dedicated team at SaltStack handles pull requests and another team works on triaging github issues to input them into their internal SCRUM process. There are a lot of duplicate issues and old inactive issues that need attention and clutter the issue tracker. Help will be welcome.
    • Continuous integration is based on Jenkins and spins up VMs to test pull request. There is work in progress to test multiple clouds, various latencies and loads.
    • For the Docker integration, salt now keeps track of forwarded ports and relevant information about the containers.
    • salt-virt bumped into problems with chroots and timeouts due to ZMQ.
    • Multi-master: the problem lies with syncronisation of data which is sent to minions but also the data that is sent to the masters. Possible solutions to be explored are : the use of gitfs, there is no built-in solution for keys (salt-key has to be run on all masters), mine.send should send the data at both masters, for the jobs cache: one could use an external returner.
    • Thomas talked briefly about ioflo which should bring queuing, data hierarchy and data pub-sub to Salt.
    • About the rolling release question: versions in Salt are definitely not git snapshots, things get backported into previous versions. No clear definition yet of length of LTS versions.
    • salt-cloud and libcloud : in the next release, libcloud will not be a hard dependency. Some clouds didn't work in libcloud (for example AWS), so these providers got implemented directly in salt-cloud or by using third-party libraries (eg. python-boto).
    • Documentation: a sprint is planned next week. Reference documentation will not be completly revamped, but tutorial content will be added.

    Boris Feld showed a demo of vagrant images orchestrated by salt and a web UI to monitor a salt install.

    Thanks again to Thomas Hatch for coming and meeting up with (part of) the community here in France.

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

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

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

  • Salt April Meetup in Paris (France)

    2014/05/14 by Arthur Lutz

    On the 15th of april, in Paris (France), we took part in yet another Salt meetup. The community is now meeting up once every two months.

    We had two presentations:

    • Arthur Lutz made an introduction to returners and the scheduler using the SalMon monitoring system as an example. Salt is not only about configuration management Indeed!
    • The folks from Is Cool Entertainment did a presentation about how they are using salt-cloud to deploy and orchestrate clusters of EC2 machines (islands in their jargon) to reproduce parts of their production environment for testing and developement.

    More discussions about various salty subjects followed and were pursued in an Italian restaurant (photos here).

    In case it is not already in your diary : Thomas Hatch is coming to Paris next week, on Monday the 19th of May, and will be speaking at dotscale during the day and at a Salt meetup in the evening. The Salt Meetup will take place at IRILL (like the previous meetups, thanks again to them) and should start at 19h. The meetup is free and open to the public, but registering on this framadate would be appreciated.

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

  • Pylint 1.2 released!

    2014/04/22 by Sylvain Thenault

    Once again, a lot of work has been achieved since the latest 1.1 release. Claudiu, who joined the maintainer team (Torsten and me) did a great work in the past few months. Also lately Torsten has backported a lot of things from their internal G[oogle]Pylint. Last but not least, various people contributed by reporting issues and proposing pull requests. So thanks to everybody!

    Notice Pylint 1.2 depends on astroid 1.1 which has been released at the same time. Currently, code is available on Pypi, and Debian/Ubuntu packages should be ready shortly on Logilab's acceptance repositories.

    Below is the changes summary, check the changelog for more info.

    New and improved checks:

    • New message 'eval-used' checking that the builtin function eval was used.
    • New message 'bad-reversed-sequence' checking that the reversed builtin receive a sequence (i.e. something that implements __getitem__ and __len__, without being a dict or a dict subclass) or an instance which implements __reversed__.
    • New message 'bad-exception-context' checking that raise ... from ... uses a proper exception context (None or an exception).
    • New message 'abstract-class-instantiated' warning when abstract classes created with abc module and with abstract methods are instantied.
    • New messages checking for proper class __slots__: 'invalid-slots-object' and 'invalid-slots'.
    • New message 'undefined-all-variable' if a package's __all__ variable contains a missing submodule (#126).
    • New option logging-modules giving the list of module names that can be checked for 'logging-not-lazy'.
    • New option include-naming-hint to show a naming hint for invalid name (#138).
    • Mark file as a bad function when using python2 (#8).
    • Add support for enforcing multiple, but consistent name styles for different name types inside a single module.
    • Warn about empty docstrings on overridden methods.
    • Inspect arguments given to constructor calls, and emit relevant warnings.
    • Extend the number of cases in which logging calls are detected (#182).
    • Enhance the check for 'used-before-assignment' to look for nonlocal uses.
    • Improve cyclic import detection in the case of packages.

    Bug fixes:

    • Do not warn about 'return-arg-in-generator' in Python 3.3+.
    • Do not warn about 'abstract-method' when the abstract method is implemented through assignment (#155).
    • Do not register most of the 'newstyle' checker warnings with python >= 3.
    • Fix 'unused-import' false positive with augment assignment (#78).
    • Fix 'access-member-before-definition' false negative with augment assign (#164).
    • Do not crash when looking for 'used-before-assignment' in context manager assignments (#128).
    • Do not attempt to analyze non python file, eg '.so' file (#122).
    • Pass the current python path to pylint process when invoked via epylint (#133).

    Command line:

    • Add -i / --include-ids and -s / --symbols back as completely ignored options (#180).
    • Ensure init-hooks is evaluated before other options, notably load-plugins (#166).


    • Improve pragma handling to not detect 'pylint:*' strings in non-comments (#79).
    • Do not crash with UnknownMessage if an unknown message identifier/name appears in disable or enable in the configuration (#170).
    • Search for rc file in ~/.config/pylintrc if ~/.pylintrc doesn't exists (#121).
    • Python 2.5 support restored (#50 and #62).


    • Python 3.4 support
    • Enhanced support for metaclass
    • Enhanced namedtuple support

    Nice easter egg, no?

  • 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

  • Deuxième hackathon codes libres de mécanique

    2014/04/07 by Nicolas Chauvat


    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


    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 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 :

  • Code_Aster back in Debian unstable

    2014/03/31 by Denis Laxalde

    Last week, a new release of Code_Aster entered Debian unstable. Code_Aster is a finite element solver for partial differential equations in mechanics, mainly developed by EDF R&D (Électricité de France). It is arguably one of the most feature complete free software available in this domain.

    Aster has been in Debian since 2012 thanks to the work of debian-science team. Yet it has always been somehow a problematic package with a couple of persistent Release Critical (RC) bugs (FTBFS, instalability issues) and actually never entered a stable release of Debian.

    Logilab has committed to improving Code_Aster for a long time in various areas, notably through the LibAster friendly fork, which aims at turning the monolithic Aster into a library, usable from Python.

    Recently, the EDF R&D team in charge of the development of Code_Aster took several major decisions, including:

    • the move to Bitbucket forge as a sign of community opening (following the path opened by LibAster that imported the code of Code_Aster into a Mercurial repository) and,
    • the change of build system from a custom makefile-style architecture to a fine-grained Waf system (taken from that of LibAster).

    The latter obviously led to significant changes on the Debian packaging side, most of which going into a sane direction: the debian/rules file slimed down from 239 lines to 51 and a bunch of tricky install-step manipulations were dropped leading to something much simpler and closer to upstream (see #731211 for details). From upstream perspective, this re-packaging effort based on the new build-system may be the opportunity to update the installation scheme (in particular by declaring the Python library as private).

    Clearly, there's still room for improvements on both side (like building with the new metis library, shipping several versions of Aster stable/testing, MPI/serial). All in all, this is good for both Debian users and upstream developers. At Logilab, we hope that this effort will consolidate our collaboration with EDF R&D.

  • 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
            MyElement ();
            MyElement (string);
                string Name(){ return _name; }
                virtual ~MyElement ();
            string _name;
    typedef SmartPtr<MyElement> SPMyElement;
    #ifndef SMART_PTR_H
    #define SMART_PTR_H
    template <class T> class SmartPtr
            const T* getRealPointer() const;
            T* _pObj;
    SPMyElement BuildElement();
    void UseElement(SPMyElement elt);


    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.

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


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

    from distutils.core import setup
    from Cython.Build import cythonize


    from libcpp.string cimport string
    cdef extern from "src/SmartPtr.h":
        cdef cppclass SmartPtr[T]:
            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:
            string Name()
    cdef extern from "src/Test.h":
        SmartPtr[MyElement] BuildSPElement()
        void UseSPElement(SmartPtr[MyElement])


    # 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())
                self.thisptr = SmartPtr[MyElement](new MyElement(name))
        def get_name(self):
            """ Returns the name of the element """
            return self.thisptr.getRealPointer().Name()
    def build_sp_elt():
        """ Calls the C++ API to build an element """
        elt = PySPMyElement.__new__(PySPMyElement)
        elt.thisptr = BuildSPElement()
        return elt
    def use_sp_elt(elt):
        """ Lends elt to the C++ API """


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

    • On liste dans un fichier 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 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.


    • É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++


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


    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);

    import pybindgen
    import sys
    from pybindgen import retval
    from pybindgen import param
    mod = pybindgen.Module('smartptr')
    # File includes
    # Class MyElement
    MyElement = mod.add_class('MyElement')
    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__':


    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.


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


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


    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

    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.

  • Second Salt Meetup builds the french community

    2014/03/04 by Arthur Lutz

    On the 6th of February, the Salt community in France met in Paris to discuss Salt and choose the tools to federate itself. The meetup was kindly hosted by IRILL.

    There were two formal presentations :

    • Logilab did a short introduction of Salt,
    • Majerti presented a feedback of their experience with Salt in various professional contexts.

    The presentation space was then opened to other participants and Boris Feld did a short presentation of how Salt was used at NovaPost.

    We then had a short break to share some pizza (sponsored by Logilab).

    After the break, we had some open discussion about various subjects, including "best practices" in Salt and some specific use cases. Regis Leroy talked about the states that Makina Corpus has been publishing on github. The idea of reconciling the documentation and the monitoring of an infrastructure was brought up by Logilab, that calls it "Test Driven Infrastructure".

    The tools we collectively chose to form the community were the following :

    • a mailing-list kindly hosted by the AFPY (a pythonic french organization)
    • a dedicated #salt-fr IRC channel on freenode

    We decided that the meetup would take place every two months, hence the third one will be in April. There is already some discussion about organizing events to tell as many people as possible about Salt. It will probably start with an event at NUMA in March.

    After the meetup was officially over, a few people went on to have some drinks nearby. Thank you all for coming and your participation.

    login or register to comment on this blog

  • FOSDEM PGDay 2014

    2014/02/11 by Rémi Cardona

    I attended PGDay on January 31st, in Brussels. This event was held just before FOSDEM, which I also attended (expect another blog post). Here are some of the notes I took during the conference.

    Statistics in PostgreSQL, Heikki Linnakangas

    Due to transit delays, I only caught the last half of that talk.

    The main goal of this talk was to explain some of Postgres' per-column statistics. In a nutshell, Postgres needs to have some idea about tables' content in order to choose an appropriate query plan.

    Heikki explained which sorts of statistics gathers, such as most common values and histograms. Another interesting stat is the correlation between physical pages and data ordering (see CLUSTER).

    Column statistics are gathered when running ANALYZE and stored in the pg_statistic system catalog. The pg_stats view provides a human-readable version of these stats.

    Heikki also explained how to determine whether performance issues are due to out-of-date statistics or not. As it turns out, EXPLAIN ANALYZE shows for each step of the query planner how many rows it expects to process and how many it actually processed. The rule of thumb is that similar values (no more than an order of magnitude apart) mean that column statistics are doing their job. A wider margin between expected and actual rows mean that statistics are possibly preventing the query planner from picking a more optimized plan.

    It was noted though that statistics-related performance issues often happen on tables with very frequent modifications. Running ANALYZE manually or increasing the frequency of the automatic ANALYZE may help in those situations.

    Advanced Extension Use Cases, Dimitri Fontaine

    Dimitri explained with very simple cases the use of some of Postgres' lesser-known extensions and the overall extension mechanism.

    Here's a grocery-list of the extensions and types he introduced:

    • intarray extension, which adds operators and functions to the standard ARRAY type, specifically tailored for arrays of integers,
    • the standard POINT type which provides basic 2D flat-earth geometry,
    • the cube extension that can represent N-dimensional points and volumes,
    • the earthdistance extension that builds on cube to provide distance functions on a sphere-shaped Earth (a close-enough approximation for many uses),
    • the pg_trgm extension which provides text similarity functions based on trigram matching (a much simpler thus faster alternative to Levenshtein distances), especially useful for "typo-resistant" auto-completion suggestions,
    • the hstore extension which provides a simple-but-efficient key value store that has everyone talking in the Postgres world (it's touted as the NoSQL killer),
    • the hll extensions which implements the HyperLogLog algorithm which seems very well suited to storing and counting unique visitor on a web site, for example.

    An all-around great talk with simple but meaningful examples.

    Integrated cache invalidation for better hit ratios, Magnus Hagander

    What Magnus presented almost amounted to a tutorial on caching strategies for busy web sites. He went through simple examples, using the ubiquitous Django framework for the web view part and Varnish for the HTTP caching part.

    The whole talk revolved around adding private (X-prefixed) HTTP headers in replies containing one or more "entity IDs" so that Varnish's cache can be purged whenever said entities change. The hard problem lies in how and when to call PURGE on Varnish.

    The obvious solution is to override Django's save() method on Model-derived objects. One can then use httplib (or better yet requests) to purge the cache. This solution can be slightly improved by using Django's signal mechanism instead, which sound an awful-lot like CubicWeb's hooks.

    The problem with the above solution is that any DB modification not going through Django (and they will happen) will not invalidate the cached pages. So Magnus then presented how to write the same cache-invalidating code in PL/Python in triggers.

    While this does solve that last issue, it introduces synchronous HTTP calls in the DB, killing write performance completely (or killing it completely if the HTTP calls fail). So to fix those problems, while introducing limited latency, is to use SkyTools' PgQ, a simple message queue based on Postgres. Moving the HTTP calls outside of the main database and into a Consumer (a class provided by PgQ's python bindings) makes the cache-invalidating trigger asynchronous, reducing write overhead.

    A clear, concise and useful talk for any developer in charge of high-traffic web sites or applications.

    The Worst Day of Your Life, Christophe Pettus

    Christophe humorously went back to that dreadful day in the collective Postgres memory: the release of 9.3.1 and the streaming replication chaos.

    My overall impression of the talk: Thank $DEITY I'm not a DBA!

    But Christophe also gave some valuable advice, even for non-DBAs:

    • Provision 3 times the necessary disk space, in case you need to pg_dump or otherwise do a snapshot of your currently running database,
    • Do backups and test them:
      • give them to developers,
      • use them for analytics,
      • test the restore, make it foolproof, try to automate it,
    • basic Postgres hygiene:
      • fsync = on (on by default, DON'T TURN IT OFF, there are better ways)
      • full_page_writes = on (on by default, don't turn it off)
      • deploy minor versions as soon as possible,
      • plan upgrade strategies before EOL,
      • 9.3+ checksums (createdb option, performance cost is minimal),
      • application-level consistency checks (don't wait for auto vacuum to "discover" consistency errors).

    Materialised views now and in the future, Thom Brown

    Thom presented on of the new features of Postgres 9.3, materialized views.

    In a nutshell, materialized views (MV) are read-only snapshots of queried data that's stored on disk, mostly for performance reasons. An interesting feature of materialized views is that they can have indexes, just like regular tables.

    The REFRESH MATERIALIZED VIEW command can be used to update an MV: it will simply run the original query again and store the new results.

    There are a number of caveats with the current implementation of MVs:

    • pg_dump never saves the data, only the query used to build it,
    • REFRESH requires an exclusive lock,
    • due to implementation details (frozen rows or pages IIRC), MVs may exhibit non-concurrent behavior with other running transactions.

    Looking towards 9.4 and beyond, here are some of the upcoming MV features:

    • 9.4 adds the CONCURRENTLY keyword:
      • + no longer needs an exclusive lock, doesn't block reads
      • - requires a unique index
      • - may require VACUUM
    • roadmap (no guarantees):
      • unlogged (disables the WAL),
      • incremental refresh,
      • lazy automatic refresh,
      • planner awareness of MVs (would use MVs as cache/index).

    Indexes: The neglected performance all-rounder, Markus Winand

    Markus' goal with this talk showed that very few people in the SQL world actually know - let alone really care - about indexes. According to his own experience and that of others (even with competing RDBMS), poorly written SQL is still a leading cause of production downtime (he puts the number at around 50% of downtime though others he quoted put that number higher). SQL queries can indeed put such stress on DB systems and cause them to fail.

    One major issue, he argues, is poorly designed indexes. He went back in time to explain possible reasons for the lack of knowledge about indexes with both SQL developers and DBAs. One such reason may be that indexes are not part of the SQL standard and are left as implementation-specific details. Thus many books about SQL barely cover indexes, if at all.

    He then took us through a simple quiz he wrote on the topic, with only 5 questions. The questions and explanations were very insightful and I must admit my knowledge of indexes was not up to par. I think everyone in the room got his message loud and clear: indexes are part of the schema, devs should care about them too.

    Try out the test :

    PostgreSQL - Community meets Business, Michael Meskes

    For the last talk of the day, Michael went back to the history of the Postgres project and its community. Unlike other IT domains such as email, HTTP servers or even operating systems, RDBMS are still largely dominated by proprietary vendors such as Oracle, IBM and Microsoft. He argues that the reasons are not technical: from a developer stand point, Postgres has all the features of the leading RDMBS (and many more) and the few missing administrative features related to scalability are being addressed.

    Instead, he argues decision makers inside companies don't yet fully trust Postgres due to its (perceived) lack of corporate backers.

    He went on to suggest ways to overcome those perceptions, for example with an "official" Postgres certification program.

    A motivational talk for the Postgres community.

  • A Salt Configuration for C++ Development

    2014/01/24 by Damien Garaud

    At Logilab, we've been using Salt for one year to manage our own infrastructure. I wanted to use it to manage a specific configuration: C++ development. When I instantiate a Virtual Machine with a Debian image, I don't want to spend time to install and configure a system which fits my needs as a C++ developer:

    This article is a very simple recipe to get a C++ development environment, ready to use, ready to hack.

    Give Me an Editor and a DVCS

    Quite simple: I use the YAML file format used by Salt to describe what I want. To install these two editors, I just need to write:


    For Mercurial, you'll guess:


    You can write these lines in the same init.sls file, but you can also decide to split your configuration into different subdirectories: one place for each thing. I decided to create a dev and editor directories at the root of my salt config with two init.sls inside.

    That's all for the editors. Next step: specific C++ development packages.

    Install Several "C++" Packages

    In a cpp folder, I write a file init.sls with this content:


    The choice of these packages is arbitrary. You add or remove some as you need. There is not a unique right solution. But I want more. I want some LLVM packages. In a cpp/llvm.sls, I write:

    {% if not grains['oscodename'] == 'wheezy' %}
    {% endif %}

    The last line specifies that you install the lldb package if your Debian release is not the stable one, i.e. jessie/testing or sid in my case. Now, just include this file in the init.sls one:

    # ...
    # at the end of 'cpp/init.sls'
      - .llvm

    Organize your sls files according to your needs. That's all for packages installation. You Salt configuration now looks like this:

    |-- cpp
    |   |-- init.sls
    |   `-- llvm.sls
    |-- dev
    |   `-- init.sls
    |-- edit
    |   `-- init.sls
    `-- top.sls

    Launching Salt

    Start your VM and install a masterless Salt on it (e.g. apt-get install salt-minion). For launching Salt locally on your naked VM, you need to copy your configuration (through scp or a DVCS) into /srv/salt/ directory and to write the file top.sls:

        - dev
        - edit
        - cpp

    Then just launch:

    > salt-call --local state.highstate

    as root.

    And What About Configuration Files?

    You're right. At the beginning of the post, I talked about a "ready to use" Mercurial with some HG extensions. So I use and copy the default /etc/mercurial/hgrc.d/hgext.rc file into the dev directory of my Salt configuration. Then, I edit it to set some extensions such as color, rebase, pager. As I also need Evolve, I have to clone the source code from With Salt, I can tell "clone this repo and copy this file" to specific places.

    So, I add some lines to dev/init.sls.
          - rev: tip
          - target: /opt/local/mutable-history
          - require:
             - pkg: mercurial
          - source: salt://dev/hgext.rc
          - user: root
          - group: root
          - mode: 644

    The require keyword means "install (if necessary) this target before cloning". The other lines are quite self-explanatory.

    In the end, you have just six files with a few lines. Your configuration now looks like:

    |-- cpp
    |   |-- init.sls
    |   `-- llvm.sls
    |-- dev
    |   |-- hgext.rc
    |   `-- init.sls
    |-- edit
    |   `-- init.sls
    `-- top.sls

    You can customize it and share it with your teammates. A step further would be to add some configuration files for your favorite editor. You can also imagine to install extra packages that your library depends on. Quite simply add a subdirectory amazing_lib and write your own init.sls. I know I often need Boost libraries for example. When your Salt configuration has changed, just type: salt-call --local state.highstate.

    As you can see, setting up your environment on a fresh system will take you only a couple commands at the shell before you are ready to compile your C++ library, debug it, fix it and commit your modifications to your repository.

  • What's New in Pandas 0.13?

    2014/01/19 by Damien Garaud

    Do you know pandas, a Python library for data analysis? Version 0.13 came out on January the 16th and this post describes a few new features and improvements that I think are important.

    Each release has its list of bug fixes and API changes. You may read the full release note if you want all the details, but I will just focus on a few things.

    You may be interested in one of my previous blog post that showed a few useful Pandas features with datasets from the Quandl website and came with an IPython Notebook for reproducing the results.

    Let's talk about some new and improved Pandas features. I suppose that you have some knowledge of Pandas features and main objects such as Series and DataFrame. If not, I suggest you watch the tutorial video by Wes McKinney on the main page of the project or to read 10 Minutes to Pandas in the documentation.


    I welcome the refactoring effort: the Series type, subclassed from ndarray, has now the same base class as DataFrame and Panel, i.e. NDFrame. This work unifies methods and behaviors for these classes. Be aware that you can hit two potential incompatibilities with versions less that 0.13. See internal refactoring for more details.



    Function pd.to_timedelta to convert a string, scalar or array of strings to a Numpy timedelta type (np.timedelta64 in nanoseconds). It requires a Numpy version >= 1.7. You can handle an array of timedeltas, divide it by an other timedelta to carry out a frequency conversion.

    from datetime import timedelta
    import numpy as np
    import pandas as pd
    # Create a Series of timedelta from two DatetimeIndex.
    dr1 = pd.date_range('2013/06/23', periods=5)
    dr2 = pd.date_range('2013/07/17', periods=5)
    td = pd.Series(dr2) - pd.Series(dr1)
    # Set some Na{N,T} values.
    td[2] -= np.timedelta64(timedelta(minutes=10, seconds=7))
    td[3] = np.nan
    td[4] += np.timedelta64(timedelta(hours=14, minutes=33))
    0   24 days, 00:00:00
    1   24 days, 00:00:00
    2   23 days, 23:49:53
    3                 NaT
    4   24 days, 14:33:00
    dtype: timedelta64[ns]

    Note the NaT type (instead of the well-known NaN). For day conversion:

    td / np.timedelta64(1, 'D')
    0    24.000000
    1    24.000000
    2    23.992975
    3          NaN
    4    24.606250
    dtype: float64

    You can also use the DateOffSet as:

    td + pd.offsets.Minute(10) - pd.offsets.Second(7) + pd.offsets.Milli(102)

    Nanosecond Time

    Support for nanosecond time as an offset. See pd.offsets.Nano. You can use N of this offset in the pd.date_range function as the value of the argument freq.

    Daylight Savings

    The tz_localize method can now infer a fall daylight savings transition based on the structure of the unlocalized data. This method, as the tz_convert method is available for any DatetimeIndex, Series and DataFrame with a DatetimeIndex. You can use it to localize your datasets thanks to the pytz module or convert your timeseries to a different time zone. See the related documentation about time zone handling. To use the daylight savings inference in the method tz_localize, set the infer_dst argument to True.

    DataFrame Features

    New Method isin()

    New DataFrame method isin which is used for boolean indexing. The argument to this method can be an other DataFrame, a Series, or a dictionary of a list of values. Comparing two DataFrame with isin is equivalent to do df1 == df2. But you can also check if values from a list occur in any column or check if some values for a few specific columns occur in the DataFrame (i.e. using a dict instead of a list as argument):

    df = pd.DataFrame({'A': [3, 4, 2, 5],
                       'Q': ['f', 'e', 'd', 'c'],
                       'X': [1.2, 3.4, -5.4, 3.0]})
       A  Q    X
    0  3  f  1.2
    1  4  e  3.4
    2  2  d -5.4
    3  5  c  3.0

    and then:

    df.isin(['f', 1.2, 3.0, 5, 2, 'd'])
           A      Q      X
    0   True   True   True
    1  False  False  False
    2   True   True  False
    3   True  False   True

    Of course, you can use the previous result as a mask for the current DataFrame.

    mask = _
          A  Q    X
       0  3  f  1.2
       2  2  d -5.4
       3  5  c  3.0
    When you pass a dictionary to the ``isin`` method, you can specify the column
    labels for each values.
    mask = df.isin({'A': [2, 3, 5], 'Q': ['d', 'c', 'e'], 'X': [1.2, -5.4]})
        A    Q    X
    0   3  NaN  1.2
    1 NaN    e  NaN
    2   2    d -5.4
    3   5    c  NaN

    See the related documentation for more details or different examples.

    New Method str.extract

    The new vectorized extract method from the StringMethods object, available with the suffix str on Series or DataFrame. Thus, it is possible to extract some data thanks to regular expressions as followed:

    s = pd.Series(['', '', 'wrong.mail', '', ''])
    # Extract usernames.


    0       doe
    1    nobody
    2       NaN
    3    pandas
    4       NaN
    dtype: object

    Note that the result is a Series with the re match objects. You can also add more groups as:

    # Extract usernames and domain.
            0           1
    0     doe
    1  nobody
    2     NaN         NaN
    3  pandas
    4     NaN         NaN

    Elements that do no math return NaN. You can use named groups. More useful if you want a more explicit column names (without NaN values in the following example):

    # Extract usernames and domain with named groups.
         user          at
    0     doe
    1  nobody
    3  pandas

    Thanks to this part of the documentation, I also found out other useful strings methods such as split, strip, replace, etc. when you handle a Series of str for instance. Note that the most of them have already been available in 0.8.1. Take a look at the string handling API doc (recently added) and some basics about vectorized strings methods.

    Interpolation Methods

    DataFrame has a new interpolate method, similar to Series. It was possible to interpolate missing data in a DataFrame before, but it did not take into account the dates if you had index timeseries. Now, it is possible to pass a specific interpolation method to the method function argument. You can use scipy interpolation functions such as slinear, quadratic, polynomial, and others. The time method is used to take your index timeseries into account.

    from datetime import date
    # Arbitrary timeseries
    ts = pd.DatetimeIndex([date(2006,5,2), date(2006,12,23), date(2007,4,13),
                           date(2007,6,14), date(2008,8,31)])
    df = pd.DataFrame(np.random.randn(5, 2), index=ts, columns=['X', 'Z'])
    # Fill the DataFrame with missing values.
    df['X'].iloc[[1, -1]] = np.nan
    df['Z'].iloc[3] = np.nan
                       X         Z
    2006-05-02  0.104836 -0.078031
    2006-12-23       NaN -0.589680
    2007-04-13 -1.751863  0.543744
    2007-06-14  1.210980       NaN
    2008-08-31       NaN  0.566205

    Without any optional argument, you have:

                       X         Z
    2006-05-02  0.104836 -0.078031
    2006-12-23 -0.823514 -0.589680
    2007-04-13 -1.751863  0.543744
    2007-06-14  1.210980  0.554975
    2008-08-31  1.210980  0.566205

    With the time method, you obtain:

                       X         Z
    2006-05-02  0.104836 -0.078031
    2006-12-23 -1.156217 -0.589680
    2007-04-13 -1.751863  0.543744
    2007-06-14  1.210980  0.546496
    2008-08-31  1.210980  0.566205

    I suggest you to read more examples in the missing data doc part and the scipy documentation about the module interpolate.


    Convert a Series to a single-column DataFrame with its method to_frame.

    Misc & Experimental Features

    Retrieve R Datasets

    Not a killing feature but very pleasant: the possibility to load into a DataFrame all R datasets listed at

    import pandas.rpy.common as com
    titanic = com.load_data('Titanic')
      Survived    Age     Sex Class value
    0       No  Child    Male   1st   0.0
    1       No  Child    Male   2nd   0.0
    2       No  Child    Male   3rd  35.0
    3       No  Child    Male  Crew   0.0
    4       No  Child  Female   1st   0.0

    for the datasets about survival of passengers on the Titanic. You can find several and different datasets about New York air quality measurements, body temperature series of two beavers, plant growth results or the violent crime rates by US state for instance. Very useful if you would like to show pandas to a friend, a colleague or your Grandma and you do not have a dataset with you.

    And then three great experimental features.

    Eval and Query Experimental Features

    The eval and query methods which use numexpr which can fastly evaluate array expressions as x - 0.5 * y. For numexpr, x and y are Numpy arrays. You can use this powerfull feature in pandas to evaluate different DataFrame columns. By the way, we have already talked about numexpr a few years ago in EuroScipy 09: Need for Speed.

    df = pd.DataFrame(np.random.randn(10, 3), columns=['x', 'y', 'z'])
              x         y         z
    0 -0.617131  0.460250 -0.202790
    1 -1.943937  0.682401 -0.335515
    2  1.139353  0.461892  1.055904
    3 -1.441968  0.477755  0.076249
    4 -0.375609 -1.338211 -0.852466
    df.eval('x + 0.5 * y - z').head()
    0   -0.184217
    1   -1.267222
    2    0.314395
    3   -1.279340
    4   -0.192248
    dtype: float64

    About the query method, you can select elements using a very simple query syntax.

    df.query('x >= y > z')
              x         y         z
    9  2.560888 -0.827737 -1.326839

    msgpack Serialization

    New reading and writing functions to serialize your data with the great and well-known msgpack library. Note this experimental feature does not have a stable storage format. You can imagine to use zmq to transfer msgpack serialized pandas objects over TCP, IPC or SSH for instance.

    Google BigQuery

    A recent module which provides a way to load into and extract datasets from the Google BigQuery Web service. I've not installed the requirements for this feature now. The example of the release note shows how you can select the average monthly temperature in the year 2000 across the USA. You can also read the related pandas documentation. Nevertheless, you will need a BigQuery account as the other Google's products.

    Take Your Keyboard

    Give it a try, play with some data, mangle and plot them, compute some stats, retrieve some patterns or whatever. I'm convinced that pandas will be more and more used and not only for data scientists or quantitative analysts. Open an IPython Notebook, pick up some data and let yourself be tempted by pandas.

    I think I will use more the vectorized strings methods that I found out about when writing this post. I'm glad to learn more about timeseries because I know that I'll use these features. I'm looking forward to the two experimental features such as eval/query and msgpack serialization.

    You can follow me on Twitter (@jazzydag). See also Logilab (@logilab_org).

  • Pylint 1.1 christmas release

    2013/12/24 by Sylvain Thenault

    Pylint 1.1 eventually got released on pypi!

    A lot of work has been achieved since the latest 1.0 release. Various people have contributed to add several new checks as well as various bug fixes and other enhancement.

    Here is the changes summary, check the changelog for more info.

    New checks:

    • 'deprecated-pragma', for use of deprecated pragma directives "pylint:disable-msg" or "pylint:enable-msg" (was previously emmited as a regular warn().
    • 'superfluous-parens' for unnecessary parentheses after certain keywords.
    • 'bad-context-manager' checking that '__exit__' special method accepts the right number of arguments.
    • 'raising-non-exception' / 'catching-non-exception' when raising/catching class non inheriting from BaseException
    • 'non-iterator-returned' for non-iterators returned by '__iter__'.
    • 'unpacking-non-sequence' for unpacking non-sequences in assignments and 'unbalanced-tuple-unpacking' when left-hand-side size doesn't match right-hand-side.

    Command line:

    • New option for the multi-statement warning to allow single-line if statements.
    • Allow to run pylint as a python module 'python -m pylint' (anatoly techtonik).
    • Various fixes to epylint

    Bug fixes:

    • Avoid false used-before-assignment for except handler defined identifier used on the same line (#111).
    • 'useless-else-on-loop' not emited if there is a break in the else clause of inner loop (#117).
    • Drop 'badly-implemented-container' which caused several problems in its current implementation.
    • Don't mark input as a bad function when using python3 (#110).
    • Use attribute regexp for properties in python3, as in python2
    • Fix false-positive 'trailing-whitespace' on Windows (#55)


    • Replaced regexp based format checker by a more powerful (and nit-picky) parser, combining 'no-space-after-operator', 'no-space-after-comma' and 'no-space-before-operator' into a new warning 'bad-whitespace'.
    • Create the PYLINTHOME directory when needed, it might fail and lead to spurious warnings on import of pylint.config.
    • Fix so that pylint properly install on Windows when using python3.
    • Various documentation fixes and enhancements

    Packages will be available in Logilab's Debian and Ubuntu repository in the next few weeks.

    Happy christmas!

  • SaltStack Paris Meetup on Feb 6th, 2014 - (S01E02)

    2013/12/20 by Nicolas Chauvat

    Logilab has set up the second meetup for salt users in Paris on Feb 6th, 2014 at IRILL, near Place d'Italie, starting at 18:00. The address is 23 avenue d'Italie, 75013 Paris.

    Here is the announce in french

    Please forward it to whom may be interested, underlining that pizzas will be offered to refuel the chatters ;)

    Conveniently placed a week after the Salt Conference, topics will include anything related to salt and its uses, demos, new ideas, exchange of salt formulas, commenting the talks/videos of the saltconf, etc.

    If you are interested in Salt, Python and Devops and will be in Paris at that time, we hope to see you there !

  • A quick take on continuous integration services for Bitbucket

    2013/12/19 by Sylvain Thenault

    Some time ago, we moved Pylint from this forge to Bitbucket (more on this here).

    Since then, I somewhat continued to use the continuous integration (CI) service we provide on to run tests on new commits, and to do the release job (publish a tarball on pypi, on our web site, build Debian and Ubuntu packages, etc.). This is fine, but not really handy since the's CI service is not designed to be used for projects hosted elsewhere. Also I wanted to see what others have to offer, so I decided to find a public CI service to host Pylint and Astroid automatic tests at least.

    Here are the results of my first swing at it. If you have others suggestions, some configuration proposal or whatever, please comment.

    First, here are the ones I didn't test along with why:

    The first one I actually tested, also the first one to show up when looking for "bitbucket continuous integration" on Google is The UI is really simple, I was able to set up tests for Pylint in a matter of minutes: Tests are automatically launched when a new commit is pushed to Pylint's Bitbucket repository and that setup was done automatically.

    Trying to push further, one missing feature is the ability to have different settings for my project, e.g. to launch tests on all the python flavor officially supported by Pylint (2.5, 2.6, 2.7, 3.2, 3.3, pypy, jython, etc.). Last but not least, the missing killer feature I want is the ability to launch tests on top of Pull Requests, which travis-ci supports.

    Then I gave a shot, but got stuck at the Bitbucket repository selection screen: none were displayed. Maybe because I don't own Pylint's repository, I'm only part of the admin/dev team? Anyway, wercker seems appealing too, though the configuration using yaml looks a bit more complicated than's, but as I was not able to test it further, there's not much else to say.

    So for now the winner is, but the first one allowing me to test on several Python versions and to launch tests on pull requests will be the definitive winner! Bonus points for automating the release process and checking test coverage on pull requests as well.

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

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


    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 :


    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)],

    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 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)])

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

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

    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

    À 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 ?)

    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.

  • A retrospective of 10 years animating the pylint free software projet

    2013/11/25 by Sylvain Thenault

    was the topic of the talk I gave last saturday at the Capitol du Libre in Toulouse.

    Here are the slides (pdf) for those interested (in french). A video of the talk should be available soon on the Capitol du Libre web site. The slides are mirrored on slideshare (see below):

  • Retrieve Quandl's Data and Play with a Pandas

    2013/10/31 by Damien Garaud

    This post deals with the Pandas Python library, the open and free access of timeseries datasets thanks to the Quandl website and how you can handle datasets with pandas efficiently.

    Why this post?

    There has been a long time that I want to play a little with pandas. Not an adorable black and white teddy bear but the well-known Python Data library based on Numpy. I would like to show how you can easely retrieve some numerical datasets from the Quandl website and its API, and handle these datasets with pandas efficiently trought its main object: the DataFrame.

    Note that this blog post comes with a IPython Notebook which can be found at

    You also can get it at with HG.

    Just do:

    hg clone

    and get the IPython Notebook, the HTML conversion of this Notebook and some related CSV files.

    First Step: Get the Code

    At work or at home, I use Debian. A quick and dumb apt-get install python-pandas is enough. Nevertheless, (1) I'm keen on having a fresh and bloody upstream sources to get the lastest features and (2) I'm trying to contribute a little to the project --- tiny bugs, writing some docs. So I prefer to install it from source. Thus, I pull, I do sudo python develop and a few Cython compiling seconds later, I can do:

    import pandas as pd

    For the other ways to get the library, see the download page on the official website or see the dedicated Pypi page.

    Let's build 10 brownian motions and plotting them with matplotlib.

    import numpy as np
    pd.DataFrame(np.random.randn(120, 10).cumsum(axis=0)).plot()

    I don't very like the default font and color of the matplotlib figures and curves. I know that pandas defines a "mpl style". Just after the import, you can write:

    pd.options.display.mpl_style = 'default'

    Second Step: Have You Got Some Data Please ?

    Maybe I'm wrong, but I think that it's sometimes a quite difficult to retrieve some workable numerial datasets in the huge amount of available data over the Web. Free Data, Open Data and so on. OK folks, where are they ? I don't want to spent my time to through an Open Data website, find some interesting issues, parse an Excel file, get some specific data, mangling them to get a 2D arrays of floats with labels. Note that pandas fits with these kinds of problem very well. See the IO part of the pandas documentation --- CSV, Excel, JSON, HDF5 reading/writing functions. I just want workable numerical data without making effort.

    A few days ago, a colleague of mine talked me about Quandl, a website dedicated to find and use numerical datasets with timeseries on the Internet. A perfect source to retrieve some data and play with pandas. Note that you can access some data about economics, health, population, education etc. thanks to a clever API. Get some datasets in CSV/XML/JSON formats between this date and this date, aggregate them, compute the difference, etc.

    Moreover, you can access Quandl's datasets through any programming languages, like R, Julia, Clojure or Python (also available plugins or modules for some softwares such as Excel, Stata, etc.). The Quandl's Python package depends on Numpy and pandas. Perfect ! I can use the module available on GitHub and query some datasets directly in a DataFrame.

    Here we are, huge amount of data are teasing me. Next question: which data to play with?

    Third Step: Give some Food to Pandas

    I've already imported the pandas library. Let's query some datasets thanks to the Quandl Python module. An example inspired by the README from the Quandl's GitHub page project.

    import Quandl
    data = Quandl.get('GOOG/NYSE_IBM')

    and you get:

                  Open    High     Low   Close    Volume
    2013-10-11  185.25  186.23  184.12  186.16   3232828
    2013-10-14  185.41  186.99  184.42  186.97   2663207
    2013-10-15  185.74  185.94  184.22  184.66   3367275
    2013-10-16  185.42  186.73  184.99  186.73   6717979
    2013-10-17  173.84  177.00  172.57  174.83  22368939

    OK, I'm not very familiar with this kind of data. Take a look at the Quandl website. After a dozen of minutes on the Quandl website, I found this OECD murder rates. This page shows current and historical murder rates (assault deaths per 100 000 people) for 33 countries from the OECD. Take a country and type:


    It's a DataFrame with a single column 'Value'. The index of the DataFrame is a timeserie. You can easily plot these data thanks to a:


    See the other pieces of code and using examples in the dedicated IPython Notebook. I also get data about unemployment in OECD for the quite same countries with more dates. Then, as I would like to compare these data, I must select similar countries, time-resample my data to have the same frequency and so on. Take a look. Any comment is welcomed.

    So, the remaining content of this blog post is just a summary of a few interesting and useful pandas features used in the IPython notebook.

    • Using the timeseries as Index of my DataFrames
    • pd.concat to concatenate several DataFrames along a given axis. This function can deal with missing values if the Index of each DataFrame are not similar (this is my case)
    • DataFrame.to_csv and pd.read_csv to dump/load your data to/from CSV files. There are different arguments for the read_csv which deals with dates, mising value, header & footer, etc.
    • DateOffset pandas object to deal with different time frequencies. Quite useful if you handle some data with calendar or business day, month end or begin, quarter end or begin, etc.
    • Resampling some data with the method resample. I use it to make frequency conversion of some data with timeseries.
    • Merging/joining DataFrames. Quite similar to the "SQL" feature. See pd.merge function or the DataFrame.join method. I used this feature to align my two DataFrames along its Index.
    • Some Matplotlib plotting functions such as DataFrame.plot() and plot(kind='bar').


    I showed a few useful pandas features in the IPython Notebooks: concatenation, plotting, data computation, data alignement. I think I can show more but this could be occurred in a further blog post. Any comments, suggestions or questions are welcomed.

    The next 0.13 pandas release should be coming soon. I'll write a short blog post about it in a few days.

    The pictures come from:

  • PyConFr

    2013/10/28 by Alain Leufroy

    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 bdist_wheel
    $ pypy bdist_wheel

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

    $ python sdist

    Python dans Mercurial

    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

    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)/


    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

    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

    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 !

  • SaltStack Paris Meetup - some of what was said

    2013/10/09 by Arthur Lutz

    Last week, on the first day of OpenWorldForum 2013, we met up with Thomas Hatch of SaltStack to have a talk about salt. He was in Paris to give two talks the following day (1 & 2), and it was a great opportunity to meet him and physically meet part of the French Salt community. Since Logilab hosted the Great Salt Sprint in Paris, we offered to co-organise the meetup at OpenWorldForum.


    About 15 people gathered in Montrouge (near Paris) and we all took turns to present ourselves and how or why we used salt. Some people wanted to migrate from BCFG2 to salt. Some people told the story of working a month with CFEngine and meeting the same functionnality in two days with salt and so decided to go for that instead. Some like salt because they can hack its python code. Some use salt to provision pre-defined AMI images for the clouds (salt-ami-cloud-builder). Some chose salt over Ansible. Some want to use salt to pilot temporary computation clusters in the cloud (sort of like what StarCluster does with boto and ssh).

    When Paul from Logilab introduced salt-ami-cloud-builder, Thomas Hatch said that some work is being done to go all the way : build an image from scratch from a state definition. On the question of Debian packaging, some efforts could be done to have salt into wheezy-backports. Julien Cristau from Logilab who is a debian developer might help with that.

    Some untold stories where shared : some companies that replaced puppet by salt, some companies use salt to control an HPC cluster, some companies use salt to pilot their existing puppet system.

    We had some discussions around salt-cloud, which will probably be merged into salt at some point. One idea for salt-cloud was raised : have a way of defining a "minimum" type of configuration which translates into the profiles according to which provider is used (an issue should be added shortly). The expression "pushing states" was often used, it is probably a good way of looking a the combination of using salt-cloud and the masterless mode available with salt-ssh. salt-cloud controls an existing cloud, but Thomas Hatch points to the fact that with salt-virt, salt is becoming a cloud controller itself, more on that soon.

    Mixing pillar definition between 'public' and 'private' definitions can be tricky. Some solutions exist with multiple gitfs (or mercurial) external pillar definitions, but more use cases will drive more flexible functionalities in the future.

    Presentation and live demo

    For those in the audience that were not (yet) users of salt, Thomas went back to explaining a few basics about it. Salt should be seen as a "toolkit to solve problems in a infrastructure" says Thomas Hatch. Why is it fast ? It is completely asynchronous and event driven.

    He gave a quick presentation about the new salt-ssh which was introduced in 0.17, which allows the application of salt recipes to machines that don't have a minion connected to the master.

    The peer communication can be used so as to add a condition for a state on the presence of service on a different minion.

    While doing demos or even hacking on salt, one can use salt/test/ which makes fake minions, not everyone has hundreds of servers in at their fingertips.

    Smart modules are loaded dynamically, for example, the git module that gets loaded if a state installs git and then in the same highstate uses the git modules.

    Thomas explained the difference between grains and pillars : grains is data about a minion that lives on the minion, pillar is data about the minion that lives on the master. When handling grains, the grains.setval can be useful (it writes in /etc/salt/grains as yaml, so you can edit it separately). If a minion is not reachable one can obtain its grains information by replacing test=True by cache=True.

    Thomas shortly presented saltstack-formulas : people want to "program" their states, and formulas answer this need, some of the jinja2 is overly complicated to make them flexible and programmable.

    While talking about the unified package commands (a salt command often has various backends according to what system runs the minion), for example salt-call --local pkg.install vim, Thomas told this funny story : ironically, salt was nominated for "best package manager" at some linux magazine competition. (so you don't have to learn how to use FreeBSD packaging tools).

    While hacking salt, one can take a look at the Event Bus (see test/, many applications are possible when using the data on this bus. Thomas talks about a future IOflow python module where a complex logic can be implemented in the reactor with rules and a state machine. One example use of this would be if the load is high on X number of servers and the number of connexions Y on these servers then launch extra machines.

    To finish on a buzzword, someone asked "what is the overlap of salt and docker" ? The answer is not simple, but Thomas thinks that in the long run there will be a lot of overlap, one can check out the existing lxc modules and states.

    Wrap up

    To wrap up, Thomas announced a salt conference planned for January 2014 in Salt Lake City.

    Logilab proposes to bootstrap the French community around salt. As the group suggest this could take the form of a mailing list, an irc channel, a meetup group , some sprints, or a combination of all the above. On that note, next international sprint will probably take place in January 2014 around the salt conference.

  • Setup your project with cloudenvy and OpenStack

    2013/10/03 by Arthur Lutz

    One nice way of having a reproducible development or test environment is to "program" a virtual machine to do the job. If you have a powerful machine at hand you might use Vagrant in combination with VirtualBox. But if you have an OpenStack setup at hand (which is our case), you might want to setup and destroy your virtual machines on such a private cloud (or public cloud if you want or can). Sure, Vagrant has some plugins that should add OpenStack as a provider, but, here at Logilab, we have a clear preference for python over ruby. So this is where cloudenvy comes into play.

    Cloudenvy is written in python and with some simple YAML configuration can help you setup and provision some virtual machines that contain your tests or your development environment.

    Setup your authentication in ~/.cloudenvy.yml :

          os_username: username
          os_password: password
          os_tenant_name: tenant_name

    Then create an Envyfile.yml at the root of your project

      name: foo
      image: debian-wheezy-x64
      # Optional
      #remote_user: ec2-user
      #flavor_name: m1.small
      #auto_provision: False
        # files copied from your host to the VM
        #local_file : destination

    Now simply type envy up. Cloudenvy does the rest. It "simply" creates your machine, copies the files, runs your provision script and gives you it's IP address. You can then run envy ssh if you don't want to be bothered with IP addresses and such nonsense (forget about copy and paste from the OpenStack web interface, or your nova show commands).

    Little added bonus : you know your machine will run a web server on port 8080 at some point, set it up in your environment by defining in the same Envyfile.yml your access rules

    sec_groups: [
        'tcp, 22, 22,',
        'tcp, 80, 80,',
        'tcp, 8080, 8080,',

    As you might know (or I'll just recommend it), you should be able to scratch and restart your environment without loosing anything, so once in a while you'll just do envy destroy to do so. You might want to have multiples VM with the same specs, then go for envy up -n second-machine.

    Only downside right now : cloudenvy isn't packaged for debian (which is usually a prerequisite for the tools we use), but let's hope it gets some packaging soon (or maybe we'll end up doing it).

    Don't forget to include this configuration in your project's version control so that a colleague starting on the project can just type envy up and have a working setup.

    In the same order of ideas, we've been trying out salt-cloud <> because provisioning machines with SaltStack is the way forward. A blog about this is next.

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

    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.

  • DebConf13 report

    2013/09/25 by Julien Cristau

    As announced before, I spent a week last month in Vaumarcus, Switzerland, attending the 14th Debian conference (DebConf13).

    It was great to be at DebConf again, with lots of people I hadn't seen since New York City three years ago, and lots of new faces. Kudos to the organizers for pulling this off. These events are always a great boost for motivation, even if the amount of free time after coming back home is not quite as copious as I might like.

    One thing that struck me this year was the number of upstream people, not directly involved in Debian, who showed up. From systemd's Lennart and Kay, to MariaDB's Monty, and people from upstart, dracut, phpmyadmin or munin. That was a rather pleasant surprise for me.

    Here's a report on the talks and BoF sessions I attended. It's a bit long, but hey, the conference lasted a week. In addition to those I had quite a few chats with various people, including fellow members of the Debian release team.

    Day 1 (Aug 11)

    Linux kernel : Ben Hutchings made a summary of the features added between 3.2 in wheezy and the current 3.10, and their status in Debian (some still need userspace work).

    SPI status : Bdale Garbee and Jimmy Kaplowitz explained what steps SPI is making to deal with its growth, including getting help from a bookkeeper recently to relieve the pressure on the (volunteer) treasurer.

    Hardware support in Debian stable : If you buy new hardware today, it's almost certainly not supported by the Debian stable release. Ideas to improve this :

    • backport whole subsystems: probably not feasible, risk of regressions would be too high
    • ship compat-drivers, and have the installer automatically install newer drivers based on PCI ids, seems possible.
    • mesa: have the GL loader pick a different driver based on the hardware, and ship newer DRI drivers for the new hardware, without touching the old ones. Issue: need to update libGL and libglapi too when adding new drivers.
    • X drivers, drm: ? (it's complicated)

    Meeting between release team and DPL to figure out next steps for jessie. Decided to schedule a BoF later in the week.

    Day 2 (Aug 12)

    Munin project lead on new features in 2.0 (shipped in wheezy) and roadmap for 2.2. Improvements on the scalability front (both in terms of number of nodes and number of plugins on a node). Future work includes improving the UI to make it less 1990 and moving some metadata to sql.

    jeb on AWS and Debian : Amazon Web Services (AWS) includes compute (ec2), storage (s3), network (virtual private cloud, load balancing, ..) and other services. Used by Debian for package rebuilds. is a CDN frontend for archive mirrors. Official Debian images are on ec2, including on the AWS marketplace front page. build-debian-cloud tool from Anders Ingeman et al. was presented.

    openstack in Debian : Packaging work is focused on making things easy for newcomers, basic config with debconf. Advanced users are going to use puppet or similar anyway. Essex is in wheezy, but end-of-life upstream. Grizzly available in sid and in a separate archive for wheezy. This work is sponsored by enovance.

    Patents :, looks like the USPTO has used comments made there when rejecting patent applications based on prior art. Patent applications are public, and it's a lot easier to get a patent application rejected than invalidate a patent later on. Should we use that site? Help build momentum around it? Would other patent offices use that kind of research? Issues: looking at patent applications (and publicly commenting) might mean you're liable for treble damages if the patent is eventually granted? Can you comment anonymously?

    Why systemd? : Lennart and Kay. Pop corn, upstart trolling, nothing really new.

    Day 3 (Aug 13)

    dracut : dracut presented by Harald Hoyer, its main developer. Seems worth investigating replacing initramfs-tools and sharing the maintenance load. Different hooks though, so we'll need to coordinate this with various packages.

    upstart : More Debian-focused than the systemd talk. Not helped by Canonical's CLA...

    dh_busfactor : debhelper is essentially a one-man show from the beginning. Though various packages/people maintain different dh_* tools either in the debhelper package itself or elsewhere. Joey is thinking about creating a debhelper team including those people. Concerns over increased breakage while people get up to speed (joeyh has 10 years of experience and still occasionally breaks stuff).

    dri3000 : Keith is trying to fix dri2 issues. While dri2 fixed a number of things that were wrong with dri1, it still has some problems. One of the goals is to improve presentation: we need a way to sync between app and compositor (to avoid displaying incompletely drawn frames), avoid tearing, and let the app choose immediate page flip instead of waiting for next vblank if it missed its target (stutter in games is painful). He described this work on his blog.

    security team BoF : explain the workflow, try to improve documentation of the process and what people can do to help.

    Day 4 (Aug 14)

    day trip, and conference dinner on a boat from Neuchatel to Vaumarcus

    Day 5 (Aug 15)

    git-dpm : Spent half an hour explaining git, then was rushed to show git-dpm itself. Still, needs looking at. Lets you work with git and export changes as quilt series to build a source package.

    Ubuntu daily QA : The goal was to make it possible for canonical devs (not necessarily people working on the distro) to use ubuntu+1 (dev release). They tried syncing from testing for a while, but noticed bug fixes being delayed: not good. In the previous workflow the dev release was unusable/uninstallable for the first few months. Multiarch made things even more problematic because it requires amd64/i386 being in sync.

    • 12.04: a bunch of manpower thrown at ubuntu+1 to keep backlog of technical debt under control.
    • 12.10: prepare infrastructure (mostly launchpad), add APIs, to make non-canonical people able to do stuff that previously required shell access on central machines.
    • 13.04: proposed migration. britney is used to migrate packages from devel-proposed to devel. A few teething problems at first, but good reaction.
    • 13.10 and beyond: autopkgtest runs triggered after upload/build, also for rdeps. Phased updates for stable releases (rolled out to a subset of users and then gradually generalized). Hook into to match new crashes with package uploads. Generally more continuous integration. Better dashboard. (Some of that is still to be done.)

    Lessons learned from debian:

    • unstable's backlog can get bad → proposed is only used for builds and automated tests, no delay
    • transitions can take weeks at best
    • to avoid dividing human attention, devs are focused on devel, not devel-proposed

    Lessons debian could learn:

    • keeping testing current is a collective duty/win
    • splitting users between testing and unstable has important costs
    • hooking automated testing into britney really powerful; there's a small but growing number of automated tests


    • cut migration delay in half
    • encourage writing autopkgtests
    • end goal: make sid to testing migration entirely based on automated tests

    Debian tests using Jenkins

    • Only running amd64 right now.
    • Uses jenkins plugins: git, svn, log parser, html publisher, ...
    • Has existing jobs for installer, chroot installs, others
    • Tries to make it easy to reproduce jobs, to allow debugging
    • {c,sh}ould add autopkgtests

    Day 6 (Aug 16)

    X Strike Force BoF : Too many bugs we can't do anything about: {mass,auto}-close them, asking people to report upstream. Reduce distraction by moving the non-X stuff to separate teams (compiz removed instead, wayland to discuss...). We should keep drivers as close to upstream as possible. A couple of people in the room volunteered to handle the intel, ati and input drivers.

    reclass BoF

    I had missed the talk about reclass, and Martin kindly offered to give a followup BoF to show what reclass can do.

    Reclass provides adaptors for puppet(?), salt, ansible. A yaml file describes each host:

    • can declare applications and parameters
    • host is leaf in a dag/tree of classes

    Lets you put the data in reclass instead of the config management tool, keeping generic templates in ansible/salt.

    I'm definitely going to try this and see if it makes it easier to organize data we're currently putting directly in salt states.

    release BoF : Notes are on Basic summary: "Releasing in general is hard. Releasing something as big/diverse/distributed as Debian is even harder." Who knew?

    freedombox : status update from Bdale

    Keith Packard showed off the free software he uses in his and Bdale's rockets adventures.

    This was followed by a birthday party in the evening, as Debian turned 20 years old.

    Day 7 (Aug 17)

    x2go : Notes are on To be solved: issues with nx libs (gpl fork of old x). Seems like a good thing to try as alternative to LTSP which we use at Logilab.

    lightning talks

    • coquelicot (lunar) - one-click secure(ish) file upload web app
    • notmuch (bremner) - need to try that again now that I have slightly more disk space
    • fedmsg (laarmen) - GSoC, message passing inside the debian infrastructure

    Debconf15 bids :

    • Mechelen/Belgium - Wouter
    • Germany (no city yet) - Marga

    Debconf14 presentation : Will be in Portland (Portland State University) next August. Presentation by vorlon, harmoney, keithp. Looking forward to it!

    • Closing ceremony

    The videos of most of the talks can be downloaded, thanks to the awesome work of the video team. And if you want to check what I didn't see or talk about, check the complete schedule.

  • JDEV2013 - Software development conference of CNRS

    2013/09/13 by Nicolas Chauvat

    I had the pleasure to be invited to lead a tutorial at JDEV2013 titled Learning TDD and Python in Dojo mode.

    I quickly introduced the keywords with a single slide to keep it simple:
    + Test Driven Development (Test, Code, Refactor)
    + Dojo (house of training: Kata / Randori)
    = Calculators
      - Reverse Polish Notation
      - Formulas with Roman Numbers
      - Formulas with Numbers in letters

    As you can see, I had three types of calculators, hence at least three Kata to practice, but as usual with beginners, it took us the whole tutorial to get done with the first one.

    The room was a class room that we set up as our coding dojo with the coder and his copilot working on a laptop, facing the rest of the participants, with the large screen at their back. The pair-programmers could freely discuss with the people facing them, who were following the typing on the large screen.

    We switched every ten minutes: the copilot became coder, the coder went back to his seat in the class and someone else stood up to became the copilot.

    The session was allocated 3 hours split over two slots of 1h30. It took me less than 10 minutes to open the session with the above slide, 10 minutes as first coder and 10 minutes to close it. Over a time span of 3 hours, that left 150 minutes for coding, hence 15 people. Luckily, the whole group was about that size and almost everyone got a chance to type.

    I completely skipped explaining Python, its syntax and the unittest framework and we jumped right into writing our first tests with if and print statements. Since they knew about other programming languages, they picked up the Python langage on the way.

    After more than an hour of slowly discovering Python and TDD, someone in the room realized they had been focusing more on handling exception cases and failures than implementing the parsing and computation of the formulas because the specifications where not clearly understood. He then asked me the right question by trying to define Reverse Polish Notation in one sentence and checking that he got it right.

    Different algorithms to parse and compute RPN formulas where devised at the blackboard over the pause while part of the group went for a coffee break.

    The implementation took about another hour to get right, with me making sure they would not wander too far from the actual goal. Once the stack-based solution was found and implemented, I asked them to delete the files, switch coder and start again. They had forgotten about the Kata definition and were surprised, but quickly enjoyed it when they realized that progress was much faster on the second attempt.

    Since it is always better to show that you can walk the talk, I closed the session by praticing the RPN calculator kata myself in a bit less than 10 minutes. The order in which to write the tests is the tricky part, because it can easily appear far-fetched for such a small problem when you already know an algorithm that solves it.

    Here it is:

    import operator
    OPERATORS = {'+': operator.add,
                 '*': operator.mul,
                 '/': operator.div,
                 '-': operator.sub,
    def compute(args):
        items = args.split()
        stack = []
        for item in items:
            if item in OPERATORS:
                b,a = stack.pop(), stack.pop()
        return stack[0]

    with the accompanying tests:

    import unittest
    from npi import compute
    class TestTC(unittest.TestCase):
        def test_unit(self):
            self.assertEqual(compute('1'), 1)
        def test_dual(self):
            self.assertEqual(compute('1 2 +'), 3)
        def test_tri(self):
            self.assertEqual(compute('1 2 3 + +'), 6)
            self.assertEqual(compute('1 2 + 3 +'), 6)
        def test_precedence(self):
            self.assertEqual(compute('1 2 + 3 *'), 9)
            self.assertEqual(compute('1 2 * 3 +'), 5)
        def test_zerodiv(self):
            self.assertRaises(ZeroDivisionError, compute, '10 0 /')

    Apparently, it did not go too bad, for I had positive comments at the end from people that enjoyed discovering in a single session Python, Test Driven Development and the Dojo mode of learning.

    I had fun doing this tutorial and thank the organizators for this conference!

  • Going to EuroScipy2013

    2013/09/04 by Alain Leufroy

    The EuroScipy2013 conference was held in Bruxelles at the Université libre de Bruxelles.

    As usual the first two days were dedicated to tutorials while the last two ones were dedicated to scientific presentations and general python related talks. The meeting was extended by one more day for sprint sessions during which enthusiasts were able to help free software projects, namely sage, vispy and scipy.

    Jérôme and I had the great opportunity to represent Logilab during the scientific tracks and the sprint day. We enjoyed many talks about scientific applications using python. We're not going to describe the whole conference. Visit the conference website if you want the complete list of talks. In this article we will try to focus on the ones we found the most interesting.

    First of all the keynote by Cameron Neylon about Network ready research was very interesting. He presented some graphs about the impact of a group job on resolving complex problems. They revealed that there is a critical network size for which the effectiveness for solving a problem drastically increase. He pointed that the source code accessibility "friction" limits the "getting help" variable. Open sourcing software could be the best way to reduce this "friction" while unit testing and ongoing integration are facilitators. And, in general, process reproducibility is very important, not only in computing research. Retrieving experimental settings, metadata, and process environment is vital. We agree with this as we are experimenting it everyday in our work. That is why we encourage open source licenses and develop a collaborative platform that provides the distributed simulation traceability and reproducibility platform Simulagora (in french).

    Ian Ozsvald's talk dealt with key points and tips from his own experience to grow a business based on open source and python, as well as mistakes to avoid (e.g. not checking beforehand there are paying customers interested by what you want to develop). His talk was comprehensive and mentioned a wide panel of situations.

    We got a very nice presentation of a young but interesting visualization tools: Vispy. It is 6 months old and the first public release was early August. It is the result of the merge of 4 separated libraries, oriented toward interactive visualisation (vs. static figure generation for Matplotlib) and using OpenGL on GPUs to avoid CPU overload. A demonstration with large datasets showed vispy displaying millions of points in real time at 40 frames per second. During the talk we got interesting information about OpenGL features like anti-grain compared to Matplotlib Agg using CPU.

    We also got to learn about cartopy which is an open source Python library originally written for weather and climate science. It provides useful and simple API to manipulate cartographic mapping.

    Distributed computing systems was a hot topic and many talks were related to this theme.

    Gael Varoquaux reminded us what are the keys problems with "biggish data" and the key points to successfully process them. I think that some of his recommendations are generally useful like "choose simple solutions", "fail gracefully", "make it easy to debug". For big data processing when I/O limit is the constraint, first try to split the problem into random fractions of the data, then run algorithms and aggregate the results to circumvent this limit. He also presented mini-batch that takes a bunch of observations (trade-off memory usage/vectorization) and joblib.parallel that makes I/O faster using compression (CPUs are faster than disk access).

    Benoit Da Mota talked about shared memory in parallel computing and Antonio Messina gave us a quick overview on how to build a computing cluster with Elasticluster, using OpenStack/Slurm/ansible. He demonstrated starting and stopping a cluster on OpenStack: once all VMs are started, ansible configures them as hosts to the cluster and new VMs can be created and added to the cluster on the fly thanks to a command line interface.

    We also got a keynote by Peter Wang (from Continuum Analytics) about the future of data analysis with Python. As a PhD in physics I loved his metaphor of giving mass to data. He tried to explain the pain that scientists have when using databases.

    After the conference we participated to the numpy/scipy sprint. It was organized by Ralph Gommers and Pauli Virtanen. There were 18 people trying to close issues from different difficulty levels and had a quick tutorial on how easy it is to contribute: the easiest is to fork from the github project page on your own github account (you can create one for free), so that later your patch submission will be a simple "Pull Request" (PR). Clone locally your scipy fork repository, and make a new branch (git checkout -b <newbranch>) to tackle one specific issue. Once your patch is ready, commit it locally, push it on your github repository and from the github interface choose "Push request". You will be able to add something to your commit message before your PR is sent and looked at by the project lead developers. For example using "gh-XXXX" in your commit message will automatically add a link to the issue no. XXXX. Here is the list of open issues for scipy; you can filter them, e.g. displaying only the ones considered easy to fix :D

    For more information: Contributing to SciPy.

  • Emacs turned into a IDE with CEDET

    2013/08/29 by Anthony Truchet


    In this post you will find one way, namely thanks to CEDET, of turning your Emacs into an IDE offering features for semantic browsing and refactoring assistance similar to what you can find in major IDE like Visual Studio or Eclipse.


    Emacs is a tool of choice for the developer: it is very powerful, highly configurable and has a wealth of so called modes to improve many aspects of daily work, especially when editing code.

    The point, as you might have realised in case you have already worked with an IDE like Eclipse or Visual Studio, is that Emacs (code) browsing abilities are quite rudimentary... at least out of the box!

    In this post I will walk through one way to configure Emacs + CEDET which works for me. This is by far not the only way to get to it but finding this path required several days of wandering between inconsistent resources, distribution pitfall and the like.

    I will try to convey relevant parts of what I have learnt on the way, to warn about some pitfalls and also to indicate some interesting direction I haven't followed (be it by choice or necessity) and encourage you to try. Should you try to push this adventure further, your experience will be very much appreciated... and in any case your feedback on this post is also very welcome.

    The first part gives some deemed useful background to understand what's going on. If you want to go straight to the how-to please jump directly to the second part.

    Sketch map of the jungle

    This all started because I needed a development environment to do work remotely on a big, legacy C++ code base from quite a lightweight machine and a weak network connection.

    My former habit of using Eclipse CDT and compiling locally was not an option any longer but I couldn't stick to a bare text editor plus remote compilation either because of the complexity of the code base. So I googled emacs IDE code browser and started this journey to set CEDET + ECB up...

    I quickly got lost in a jungle of seemingly inconsistent options and I reckon that some background facts are welcome at this point as to why.

    Up to this date - sept. 2013 - most of the world is in-between two major releases of Emacs. Whereas Emacs 23.x is still packaged in many stable Linux distribution, the latest release is Emacs 24.3. In this post we will use Emacs 24.x which brings lots of improvements, two of those are really relevant to us:

    • the introduction of a package manager, which is great and (but) changes initialisation
    • the partial integration of some version of CEDET into Emacs since version 23.2

    Emacs 24 initialisation

    Very basically, Emacs used to read the user's Emacs config (~/.emacs or ~/.emacs.d/init.el) which was responsible for adapting the load-path and issuing the right (require 'stuff) commands and configuring each library in some appropriate sequence.

    Emacs 24 introduces ELPA, a new package system and official packages repository. It can be extended by other packages repositories such as Marmalade or MELPA

    By default in Emacs 24, the initialisation order is a bit more complex due to packages loading: the user's config is still read but should NOT require the libraries installed through the package system: those are automatically loaded (the former load-path adjustment and (require 'stuff) steps) after the ~/.emacs or ~/.emacs.d/init.el has finished. This makes configuring the loaded libraries much more error-prone, especially for libraries designed to be configured the old way (as of today most libraries, notably CEDET).

    Here is a good analysis of the situation and possible options. And for those interested in the details of the new initialisation process, see following sections of the manual:

    I first tried to stick to the new-way, setting up hooks in ~/.emacs.d/init.el to be called after loading the various libraries, each library having its own configuration hook, and praying for the interaction between the package manager load order and my hooks to be ok... in vain. So I ended up forcing the initialisation to the old way (see Emacs 24 below).

    What is CEDET ?

    CEDET is a Collection of Emacs Development Environment Tools. The major word here is collection, do not expect it to be an integrated environment. The main components of (or coupled with) CEDET are:

    Extract a common semantic from source code in different languages
    (e)ctags / GNU global
    Traditional (exhuberant) CTags or GNU global can be used as a source of information for Semantic
    SemanticDB provides for caching the outcome of semantic analysis in some database to reduce analysis overhead across several editing sessions
    Emacs Code Browser
    This component uses information provided by Semantic to offer a browsing GUI with windows for traversing files, classes, dependencies and the like
    This provides a notion of project analogous to most IDE. Even if the features related to building projects are very Emacs/ Linux/ Autotools-centric (and thus not necessarily very helful depending on your project setup), the main point of EDE is providing scoping of source code for Semantic to analyse and include path customisation at the project level.
    This is not part of CEDET but Semantic can be configured as a source of completions for auto-complete to propose to the user.
    and more...
    Senator, SRecode, Cogre, Speedbar, EIEIO, EAssist are other components of CEDET I've not looked at yet.

    To add some more complexity, CEDET itself is also undergoing heavy changes and is in-between major versions. The last standalone release is 1.1 but it has the old source layout and activation method. The current head of development says it is version 2.0, has new layout and activation method, plus some more features but is not released yet.

    Integration of CEDET into Emacs

    Since Emacs 23.2, CEDET is built into Emacs. More exactly parts of some version of new CEDET are built into Emacs, but of course this built-in version is older than the current head of new CEDET... As for the notable parts not built into Emacs, ECB is the most prominent! But it is packaged into Marmalade in a recent version following head of development closely which, mitigates the inconvenience.

    My first choice was using built-in CEDET with ECB installed from the packages repository: the installation was perfectly smooth but I was not able to configure cleanly enough the whole to get proper operation. Although I tried hard, I could not get Semantic to take into account the include paths I configured using my EDE project for example.

    I would strongly encourage you to try this way, as it is supposed to require much less effort to set up and less maintenance. Should you succeed I would greatly appreciate some feedback of you experience!

    As for me I got down to install the latest version from the source repositories following as closely as possible Alex Ott's advices and using his own fork of ECB to make it compliant with most recent CEDET:

    How to set up CEDET + ECB in Emacs 24

    Emacs 24

    Install Emacs 24 as you wish, I will not cover the various options here but simply summarise the local install from sources I choose.

    1. Get the source archive from
    2. Extract it somewhere and run the usual (or see the INSTALL file) - configure --prefix=~/local, - make, - make install

    Create your emacs personal directory and configuration file ~/.emacs.d/site-lisp/ and ~/.emacs.d/init.el and put this inside the latter:

    ;; this is intended for manually installed libraries
    (add-to-list 'load-path "~/.emacs.d/site-lisp/")
    ;; load the package system and add some repositories
    (require 'package)
    (add-to-list 'package-archives
                 '("marmalade" . ""))
    (add-to-list 'package-archives
                 '("melpa" . "") t)
    ;; Install a hook running post-init.el *after* initialization took place
    (add-hook 'after-init-hook (lambda () (load "post-init.el")))
    ;; Do here basic initialization, (require) non-ELPA packages, etc.
    ;; disable automatic loading of packages after init.el is done
    (setq package-enable-at-startup nil)
    ;; and force it to happen now
    ;; NOW you can (require) your ELPA packages and configure them as normal

    Useful Emacs packages

    Using the emacs commands M-x package-list-packages interactively or M-x package-install <package name>, you can install many packages easily. For example I installed:

    Choose your own! I just recommend against installing ECB or other CEDET since we are going to install those from source.

    You can also insert or load your usual Emacs configuration here, simply beware of configuring ELPA, Marmalade et al. packages after (package-initialize).


    • Get the source and put it under ~/.emacs.d/site-lisp/cedet-bzr. You can either download a snapshot from or check it out of the bazaar repository with:

      ~/.emacs.d/site-lisp$ bzr checkout --lightweight \
      bzr:// cedet-bzr
    • Run make (and optionnaly make install-info) in cedet-bzr or see the INSTALL file for more details.

    • Get Alex Ott's minimal CEDET configuration file to ~/.emacs.d/config/cedet.el for example

    • Adapt it to your system by editing the first lines as follows

      (setq cedet-root-path
          (file-name-as-directory (expand-file-name
      (add-to-list 'Info-directory-list
    • Don't forget to load it from your ~/.emacs.d/init.el:

      ;; this is intended for configuration snippets
      (add-to-list 'load-path "~/.emacs.d/")
      (load "config/cedet.el")
    • restart your emacs to check everything is OK; the --debug-init option is of great help for that purpose.


    • Get Alex Ott ECB fork into ~/.emacs.d/site-lisp/ecb-alexott:

      ~/.emacs.d/site-lisp$ git clone --depth 1
    • Run make in ecb-alexott and see the README file for more details.

    • Don't forget to load it from your ~/.emacs.d/init.el:

      (add-to-list 'load-path (expand-file-name
      (require 'ecb)
      ;(require 'ecb-autoloads)


      You can theoretically use (require 'ecb-autoloads) instead of (require 'ecb) in order to load ECB by need. I encountered various misbehaviours trying this option and finally dropped it, but I encourage you to try it and comment on your experience.

    • restart your emacs to check everything is OK (you probably want to use the --debug-init option).

    • Create a hello.cpp with you CEDET enable Emacs and say M-x ecb-activate to check that ECB is actually installed.

    Tune your configuration

    Now, it is time to tune your configuration. There is no good recipe from here onward... But I'll try to propose some snippets below. Some of them are adapted from Alex Ott personal configuration

    More Semantic options

    You can use the following lines just before (semantic-mode 1) to add to the activated features list:

    (add-to-list 'semantic-default-submodes 'global-semantic-decoration-mode)
    (add-to-list 'semantic-default-submodes 'global-semantic-idle-local-symbol-highlight-mode)
    (add-to-list 'semantic-default-submodes 'global-semantic-idle-scheduler-mode)
    (add-to-list 'semantic-default-submodes 'global-semantic-idle-completions-mode)

    You can also load additional capabilities with those lines after (semantic-mode 1):

    (require 'semantic/ia)
    (require 'semantic/bovine/gcc) ; or depending on you compiler
    ; (require 'semantic/bovine/clang)

    If you want to use auto-complete you can tell it to interface with Semantic by configuring it as follows (where AAAAMMDD.rrrr is the date.revision suffix of the version od auti-complete installed by you package manager):

    ;; Autocomplete
    (require 'auto-complete-config)
    (add-to-list 'ac-dictionary-directories (expand-file-name
    (setq ac-comphist-file (expand-file-name

    and activating it in your cedet hook, for example:

    ;; customisation of modes
    (defun alexott/cedet-hook ()
        (add-to-list 'ac-sources 'ac-source-semantic)
    ) ; defun alexott/cedet-hook ()
    Support for GNU global a/o (e)ctags
    ;; if you want to enable support for gnu global
    (when (cedet-gnu-global-version-check t)
      (semanticdb-enable-gnu-global-databases 'c-mode)
      (semanticdb-enable-gnu-global-databases 'c++-mode))
    ;; enable ctags for some languages:
    ;;  Unix Shell, Perl, Pascal, Tcl, Fortran, Asm
    (when (cedet-ectag-version-check)

    Using CEDET for development

    Once CEDET + ECB + EDE is up you can start using it for actual development. How to actually use it is beyond the scope of this already too long post. I can only invite you to have a look at:


    CEDET provides an impressive set of features both to allow your emacs environment to "understand" your code and to provide powerful interfaces to this "understanding". It is probably one of the very few solution to work with complex C++ code base in case you can't or don't want to use a heavy-weight IDE like Eclipse CDT.

    But its being highly configurable also means, at least for now, some lack of integration, or at least a pretty complex configuration. I hope this post will help you to do your first steps with CEDET and find your way to setup and configure it to you own taste.

  • Pylint 1.0 released!

    2013/08/06 by Sylvain Thenault

    Hi there,

    I'm very pleased to announce, after 10 years of existence, the 1.0 release of Pylint.

    This release has a hell long ChangeLog, thanks to many contributions and to the 10th anniversary sprint we hosted during june. More details about changes below.

    Chances are high that your Pylint score will go down with this new release that includes a lot of new checks :) Also, there are a lot of improvments on the Python 3 side (notably 3.3 support which was somewhat broken).

    You may download and install it from Pypi or from Logilab's debian repositories. Notice Pylint has been updated to use the new Astroid library (formerly known as logilab-astng) and that the logilab-common 0.60 library includes some fixes necessary for using Pylint with Python3 as well as long-awaited support for namespace packages.

    For those interested, below is a comprehensive list of what changed:

    Command line and output formating

    • A new --msg-template option to control output, deprecating "msvc" and "parseable" output formats as well as killing --include-ids and --symbols options.
    • Fix spelling of max-branchs option, now max-branches.
    • Start promoting usage of symbolic name instead of numerical ids.

    New checks

    • "missing-final-newline" (C0304) for files missing the final newline.
    • "invalid-encoded-data" (W0512) for files that contain data that cannot be decoded with the specified or default encoding.
    • "bad-open-mode" (W1501) for calls to open (or file) that specify invalid open modes (Original implementation by Sasha Issayev).
    • "old-style-class" (C1001) for classes that do not have any base class.
    • "trailing-whitespace" (C0303) that warns about trailing whitespace.
    • "unpacking-in-except" (W0712) about unpacking exceptions in handlers, which is unsupported in Python 3.
    • "old-raise-syntax" (W0121) for the deprecated syntax raise Exception, args.
    • "unbalanced-tuple-unpacking" (W0632) for unbalanced unpacking in assignments (bitbucket #37).

    Enhanced behaviours

    • Do not emit [fixme] for every line if the config value 'notes' is empty
    • Emit warnings about lines exceeding the column limit when those lines are inside multiline docstrings.
    • Name check enhancement:
      • simplified message,
      • don't double-check parameter names with the regex for parameters and inline variables,
      • don't check names of derived instance class members,
      • methods that are decorated as properties are now treated as attributes,
      • names in global statements are now checked against the regular expression for constants,
      • for toplevel name assignment, the class name regex will be used if pylint can detect that value on the right-hand side is a class (like collections.namedtuple()),
      • add new name type 'class_attribute' for attributes defined in class scope. By default, allow both const and variable names.
    • Add a configuration option for missing-docstring to optionally exempt short functions/methods/classes from the check.
    • Add the type of the offending node to missing-docstring and empty-docstring.
    • Do not warn about redefinitions of variables that match the dummy regex.
    • Do not treat all variables starting with "_" as dummy variables, only "_" itself.
    • Make the line-too-long warning configurable by adding a regex for lines for with the length limit should not be enforced.
    • Do not warn about a long line if a pylint disable option brings it above the length limit.
    • Do not flag names in nested with statements as undefined.
    • Remove string module from the default list of deprecated modules (bitbucket #3).
    • Fix incomplete-protocol false positive for read-only containers like tuple (bitbucket #25).

    Other changes

    • Support for pkgutil.extend_path and setuptools pkg_resources (logilab-common #8796).
    • New utility classes for per-checker unittests in
    • Added a new base class and interface for checkers that work on the tokens rather than the syntax, and only tokenize the input file once.
    • epylint shouldn't hang anymore when there is a large output on pylint'stderr (bitbucket #15).
    • Put back documentation in source distribution (bitbucket #6).


    • New API to make it smarter by allowing transformation functions on any node, providing a register_transform function on the manager instead of the register_transformer to make it more flexible wrt node selection
    • Use this new transformation API to provide support for namedtuple (actually in pylint-brain, logilab-astng #8766)
    • Better description of hashlib
    • Properly recognize methods annotated with abc.abstract{property,method} as abstract.
    • Added the test_utils module for building ASTs and extracting deeply nested nodes for easier testing.

  • Astroid 1.0 released!

    2013/08/02 by Sylvain Thenault

    Astroid is the new name of former logilab-astng library. It's an AST library, used as the basis of Pylint and including Python 2.5 -> 3.3 compatible tree representation, statical type inference and other features useful for advanced Python code analysis, such as an API to provide extra information when statistical inference can't overcome Python dynamic nature (see the pylint-brain project for instance).

    It has been renamed and hosted to bitbucket to make clear that this is not a Logilab dedicated project but a community project that could benefit to any people manipulating Python code (statistical analysis tools, IDE, browser, etc).

    Documentation is a bit rough but should quickly improve. Also a dedicated web-site is now online, visit (or for development).

    You may download and install it from Pypi or from Logilab's debian repositories.

  • Going to DebConf13

    2013/08/01 by Julien Cristau

    The 14th Debian developers conference (DebConf13) will take place between August 11th and August 18th in Vaumarcus, Switzerland.

    Logilab is a DebConf13 sponsor, and I'll attend the conference. There are quite a lot of cloud-related events on the schedule this year, plus the usual impromptu discussions and hallway track. Looking forward to meeting the usual suspects there!

  • We hosted the Salt Sprint in Paris

    2013/07/30 by Arthur Lutz

    Last Friday, we hosted the French event for the international Great Salt Sprint. Here is a report on what was done and discussed on this occasion.

    We started off by discussing various points that were of interest to the participants :

    • automatically write documentation from salt sls files (for Sphinx)
    • salt-mine add security layer with restricted access (bug #5467 and #6437)
    • test compatibility of salt-cloud with openstack
    • module bridge bug correction : traceback on KeyError
    • setting up the network in debian (equivalent of rh_ip)
    • configure existing monitoring solution through salt (add machines, add checks, etc) on various backends with a common syntax

    We then split up into pairs to tackle issues in small groups, with some general discussions from time to time.

    6 people participated, 5 from Logilab, 1 from nbs-system. We were expecting more participants but some couldn't make it at the last minute, or though the sprint was taking place at some other time.

    Unfortunately we had a major electricity black out all afternoon, some of us switched to battery and 3G tethering to carry on, but that couldn't last all afternoon. We ended up talking about design and use cases. ERDF (French electricity distribution company) ended up bringing generator trucks for the neighborhood !