blog entries created by Arthur Lutz
back to pagination (10 results)
  • 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.

    https://www.logilab.org/file/10132592/raw/D9cHf74XkAI49HJ.jpg

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

    https://www.logilab.org/file/10132593/raw/D9cNszLXsAAVqcX.jpg

    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.


  • Les objectifs et l'histoire des présentations internes "5mintalk"

    2019/04/16 by Arthur Lutz

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

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

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

    Tout cela se fait sur la base du volontariat.

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

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

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

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

    Les contenus sont très variés :

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

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


  • Retour sur le Workshop Prometheus et Grafana - Nantes 2019

    2019/03/08 by Arthur Lutz

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

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

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

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

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

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

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

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

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


  • Rencontres Debian Nantes - janvier 2019

    2019/01/30 by Arthur Lutz

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

    Merci à Capensis pour l’accueil dans ses locaux.

    Trois présentations ont été faites :

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

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


  • Logilab à Pas Sage en Seine 2018 #PSES2018

    2018/07/13 by Arthur Lutz

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

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

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

    Conf zero knowledge webapp

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

    Article wikipedia sur Zero Knowledge Proof

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

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

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

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

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

    Full-remote : guide de survie en environnement distant

    Encore une fois M4Dz de AlwaysData.

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

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

    Pas mal de propos sur les canaux de communication:

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

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

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

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

    Jour 2

    Privacy by design

    Notes :

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

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

    Crypto quantique

    Comment commencer à tester la crypto quantique en pratique :

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

    GRPDBookClub

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

    La RGPD pour les noobs

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

    Fin

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

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

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

    Logilab recrute!


  • Meetup Nantes Monitoring - janvier 2018 - netdata & sensu

    2018/01/31 by Arthur Lutz

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

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

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

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

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


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


  • Compte rendu Nantes Monitoring mai 2017

    2017/05/11 by Arthur Lutz

    Voici un compte rendu du Meetup Nantes Monitoring de mai 2017

    Présente ta stack

    Léo / Matlo

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

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

    Emeric / OasisWork

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

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

    Arthur / Logilab

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

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

    Quels outils choisir pour son monitoring ?

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

    Produits

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

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

    Critères

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

    Début de tableau

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

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

    Fin

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


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

    2017/02/09 by Arthur Lutz

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

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

    Objectifs

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

    Récuperer les sources et le packaging

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

    Construire sur place

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

    Gestion des dépôts

    Entrepôts d'autres technologies

    Futur


  • Linkdump du meetup docker Nantes septembre 2016

    2016/10/04 by Arthur Lutz

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

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

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

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

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

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


  • Nantes Monitoring Meetup - Septembre 2016 - Heka & Hindsight

    2016/09/14 by Arthur Lutz

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

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

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

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


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

    2016/03/11 by Arthur Lutz

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

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

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

    À lundi ?


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

    http://image.slidesharecdn.com/cfgmgmtcamp2016activesupervisionwithsalt-160203131954/95/cfgmgmtcamp-2016-roll-out-active-supervision-with-salt-graphite-and-grafana-1-638.jpg?cb=1454505737

    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.
    https://www.vaultproject.io/assets/images/hero-95b4a434.png 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.
    coffee!

    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.

    https://www.logilab.org/file/4253021/raw/16312670359_565eec1e3d_k.jpg

    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.

    http://image.slidesharecdn.com/fosdem2016describeitmonitorit-160203131836/95/fosdem-2016-after-describing-your-infrastructure-as-code-reuse-that-to-monitor-it-1-638.jpg?cb=1454505792

    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 http://video.fosdem.org/.

    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 http://data.bnf.fr/ with http://cubicweb.org/ 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).

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

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

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

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

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


  • Compte rendu meetup Agile Nantes - #lego4devops

    2016/01/08 by Arthur Lutz

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

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

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

    Photo de Axel Villechalane

    Photo de Axel Villechalane

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

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

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

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

    2015/11/20 by Arthur Lutz

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

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

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

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

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

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


  • Compte rendu Nantes Monitoring Meetup #3

    2015/11/10 by Arthur Lutz

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

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

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

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

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

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

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

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

    2015/10/27 by Arthur Lutz

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

    pyconfr

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

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

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

    Côté outils et système

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

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

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

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

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

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

    Côté bases de données

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

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

    Côté python pur

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

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

    Côté communauté

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

    Côté CubicWeb

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

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

    Hospital est un framework qui permet:

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

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

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

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

    Coté calcul scientifique

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

    Conclusion

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

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

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


  • Meetup debian Nantes octobre 2015

    2015/10/23 by Arthur Lutz

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

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

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

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


  • Nous allons à PyConFR 2015 à Pau

    2015/10/13 by Arthur Lutz

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

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

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

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

    Au plaisir de vous y croiser.


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

    2015/04/07 by Arthur Lutz

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

    Open Source Innovation Spring

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

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

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

    Logilab & Mozilla

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

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

    Intervenants de la journée

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

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

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


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

    https://www.logilab.org/file/288174/raw/68747470733a2f2f7261772e6769746875622e636f6d2f667a616e696e6f74746f2f757074696d652f646f776e6c6f6164732f636865636b5f64657461696c732e706e67.png

    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):
      uptime.monitored:
        - 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 }}:
      uptime.monitored:
        - 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.

    //www.logilab.org/file/248336/raw/Salt-Logo.png

    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.

    //www.logilab.org/file/288010/raw/IMG_3034.JPG

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

    XBUS

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

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

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

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

    Comment le packaging m'a simplifié la vie

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

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

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

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

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

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

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

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

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

    Autres liens collectés

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

    Prochain épisode

    Prochain épisode: jour 2


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

    2014/11/04 by Arthur Lutz

    Suite de pyconfr 2014 jour 1 épisode 1.

    Performance des frameworks web : Python vs the world

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

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

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

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

    CubicWeb - Vos données ont du sens

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Manipuler son code python avec RedBaron

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

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

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

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

    Prochain épisode

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


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

    2014/11/03 by Arthur Lutz

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

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

    BDD avec Behave

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

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

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

    Python + PostgreSQL

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

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

    Points à noter :

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

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

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

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

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

    Un serveur fiable avec python 3.4

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

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

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

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

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

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


  • PyconFR 2014 - on y va !

    2014/10/24 by Arthur Lutz

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

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

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

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


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

    http://www.logilab.org/file/267853/raw/saltstack_poodlebleed.jpg
    {% if salt['pkg.version']('apache2') %}
    poodle apache server restart:
        service.running:
            - name: apache2
      {% for foundfile in salt['cmd.run']('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] }}:
        file.replace:
            - 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:
        service.running:
            - name: nginx
      {% for foundfile in salt['cmd.run']('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] }}:
        file.replace:
            - 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:
        service.running:
            - name: postfix
    poodle /etc/postfix/main.cf:
    {% if 'main.cf' in salt['cmd.run']('grep smtpd_tls_mandatory_protocols /etc/postfix/main.cf') %}
        file.replace:
            - pattern: "smtpd_tls_mandatory_protocols=.*"
            - repl: "smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3"
    {% else %}
        file.append:
            - text: |
                # poodle fix
                smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
    {% endif %}
            - name: /etc/postfix/main.cf
            - watch_in:
                service: postfix
    {% endif %}
    
    {% if salt['pkg.version']('chromium') %}
    /usr/share/applications/chromium.desktop:
        file.replace:
            - pattern: Exec=/usr/bin/chromium %U
            - repl: Exec=/usr/bin/chromium --ssl-version-min=tls1 %U
    {% endif %}
    
    {% if salt['pkg.version']('iceweasel') %}
    /etc/iceweasel/pref/poodle.js:
        file.managed:
            - 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).

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

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

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

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

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

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

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

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

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


  • Lancement du blog de la communauté salt francaise

    2014/09/25 by Arthur Lutz

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

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

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


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

    http://www.logilab.org/file/263602/raw/debconf2014.png

    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.

    https://www.debian.org/logos/openlogo-100.png

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

    http://www.logilab.org/file/248338/raw/thomas-hatch.png

    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.
    http://www.logilab.org/file/248336/raw/Salt-Logo.png
    • 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.
    http://www.logilab.org/file/248335/raw/ioflo.png
    • 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.

    http://www.vagrantup.com/images/logo_vagrant-81478652.png

    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.

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

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

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

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


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

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

  • Mini compte rendu Meetup Debian à Nantes

    2014/03/13 by Arthur Lutz

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

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

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

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

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

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

    À la prochaine !

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


  • Retour sur MiniDebConf Paris 2014

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

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

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

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

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


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

    http://www.logilab.org/file/226420/raw/saltstack_meetup.jpeg

    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


  • InfoLab Rennes - 17 décembre

    2013/12/18 by Arthur Lutz

    InfoLab Rennes - 17 décembre

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

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

    Présentation générale le matin

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

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

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

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

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

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

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

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

    Atelier l'après-midi

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

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

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

    La suite

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

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


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

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

    Introduction

    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/minionswarm.py 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/eventlisten.py), 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.

    http://www.openstack.org/themes/openstack/images/open-stack-cloud-computing-logo-2.png

    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.

    http://www.python.org/images/python-logo.gif

    Setup your authentication in ~/.cloudenvy.yml :

    cloudenvy:
      clouds:
        cloud01:
          os_username: username
          os_password: password
          os_tenant_name: tenant_name
          os_auth_url: http://keystone.example.com:5000/v2.0/
    

    Then create an Envyfile.yml at the root of your project

    project_config:
      name: foo
      image: debian-wheezy-x64
    
      # Optional
      #remote_user: ec2-user
      #flavor_name: m1.small
      #auto_provision: False
      #provision_scripts:
        #- provision_script.sh
      #files:
        # 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, 0.0.0.0/0',
        'tcp, 80, 80, 0.0.0.0/0',
        'tcp, 8080, 8080, 0.0.0.0/0',
      ]
    

    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 <https://github.com/saltstack/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).

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

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

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


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

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

    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 !

    Arthur & Benoit : monitoring adding machines or checks

    http://www.logilab.org/file/157971/raw/salt-centreon-shinken.png

    Some unfinished draft code for supervision backends was written and pushed on github. We explored how a common "interface" could be done in salt (using a combination of states and __virtual___). The official documentation was often very useful, reading code was also always a good resource (and the code is really readable).

    While we were fixing stuff because of the power black out, Benoit submitted a bug fix.

    David & Alain : generate documentation from salt state & salt master

    The idea is to couple the SLS description and the current state of the salt master to generate documentation about one's infrastructure using Sphinx. This was transmitted to the mailing-list.

    http://www.logilab.org/file/157976/raw/salt-sphinx.png

    Design was done around which information should be extracted and display and how to configure access control to the salt-master, taking a further look to external_auth and salt-api will probably be the way forward.

    General discussions

    We had general discussions around concepts of access control to a salt master, on how to define this access. One of the things we believe to be missing (but haven't checked thoroughly) is the ability to separate the "read-only" operations to the "read-write" operations in states and modules, if this was done (through decorators?) we could easily tell salt-api to only give access to data collection. Complex scenarios of access were discussed. Having a configuration or external_auth based on ssh public keys (similar to mercurial-server would be nice, and would provide a "limited" shell to a mercurial server.

    Conclusion

    The power black out didn't help us get things done, but nevertheless, some sharing was done around our uses cases around SaltStack and features that we'd want to get out of it (or from third party applications). We hope to convert all the discussions into bug reports or further discussion on the mailing-lists and (obviously) into code and pull-requests. Check out the scoreboard for an overview of how the other cities contributed.

    to comment this post you need to login or create an account


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

    2013/07/01 by Arthur Lutz

    Ora2Pg: Migration à Grande Vitesse par Gilles Darold

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

    Par exemple :

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

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

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

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

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

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

    Vers le Peta Byte avec PostgreSQL par Dimitri Fontaine

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

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

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

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

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

    Comprendre EXPLAIN par Guillaume Lelarge

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

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

    Dans la même veine, les types de tris :

    • external sort (sur disque),
    • quicksort (en mémoire).

    Mais aussi, prenez le temps de lire les exemples sur son support de présentation (7)

    Conclusion

    https://www.pgday.fr/_media/pgfr2.png

    PGDay.fr est une conférence que nous pouvons vivement vous recommander, proposant un savant mélange des différentes questions auxquelles nous sommes confrontées lorsque nous travaillons avec des bases de données. Aussi bien en tant qu'administrateur système, développeur, ou utilisateur de SQL. Il va sans dire que le niveau technique était très pointu. Les présentations restaient pourtant accessibles. Les orateurs et organisateurs étaient disponibles pour des interactions, permettant de prolonger la réflexion et les discussions au delà des présentations.

    Nous envisageons d'ores et déjà d'aller à l'édition 2014! À l'année prochaine...

    http://www.logilab.org/file/150100/raw/2e1ax_default_entry_postgresql.jpg

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

    2013/07/01 by Arthur Lutz

    Quelques personnes de Logilab ont assisté aux PGDay 2013 à Nantes. Voici quelques points qui nous ont marqués.

    http://www.cubicweb.org/file/2932005/raw/hdr_left.png

    Gestion de la capacité des ressources mémoire d'un serveur PostgreSQL par Cédric Villemain

    Cédric Villemain nous a exposé plusieurs pistes d'investigation de la gestion mémoire de Postgresql.

    On peut employer des outils Linux tels que vmstat, pmap, meminfo, numactl, mais aussi des outils spécifiques à Postgresql, tels que pg_stat (hit ratio), pg_buffercache (audit de la mémoire cache), pgfincore (audit du cache de l'OS).

    Il faut mettre des sondes sur les tables et indexes critiques de manière à avoir une idée du fonctionnement "normal" pour ensuite détecter le fonctionnement "anormal". À Logilab, nous utilisons beaucoup munin, pour lequel plusieurs greffons Postgresql sont disponibles : munin pg plugins et pymunin.

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

    Les nouveautés de PostgreSQL 9.3 par Damien Clochard

    Damien Clochard a fait une très synthétique présentation des fonctionnalités de la nouvelle version de PostgreSQL 9.3. Le cycle de release de Postgresql dure 1 an, donc la periode de beta est courte, il faut que la communauté soit impliquée pour tester rapidement. Damien en profite pour chanter les louanges de PostgreSQL, qui est, selon lui, le SGBD le plus dynamique au monde: 1 version majeure par an, 4-5 versions mineures par an, et un support de 5 ans des versions majeures.

    Actuellement, cela signifie que 5 versions majeures sont maintenues (notamment en terme de sécurité) en parallèle : 8.4, 9.0, 9.1, 9.2, 9.3beta1. Notons donc que la version 9.3 qui sort bientôt sera donc supportée jusqu'à 2018.

    http://www.logilab.org/file/150442/raw/elephant.png

    Pour les nouveautés, difficiles à résumer, notons néanmoins :

    • des gains de performance,
    • des verrous possibles sur les clés étrangères,
    • une gestion mémoire plus fine,
    • la possibilité de faire des pg_dump en parallèle (--jobs),
    • scénarios supplémentaires de réplication,
    • possibilité de "bascule rapide" en architecture répliquée,
    • facilitation de mise en place d'un serveur clone (génération automatique du fichier recovery.conf),
    • vue matérialisées,
    • opérateurs supplémentaires pour JSON (citation "MongoDB avec la tranquilité (ACID)"),
    • les requètes LATERAL
    • extensibilité avec des processus supplémentaires permettant des opérations de maintenance, de supervision ou d'optimisation,
    • des backends supplémentaires pour les "Foreign Data Wrappers" (introduits en 9.1),
    • possibilité de séparer le fichier de configuration en plusieurs sous-fichiers (utile pour une pilotage par SaltStack par exemple).

    Damien en a profité pour parler un peu des points forts prévus pour la version 9.4 :

    • simplification de la montée en charge,
    • réplication logique (répliquer une seule table par exemple),
    • parallélisation des requêtes (multi-coeurs),
    • stockages internes

    En bref, concis et alléchant. Vivement qu'on ait cette version en production.

    En attendant on a profité pour l'installer à partir des entrepôts Debian gérés par la communauté Postgresql.

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

    "Ma base de données tiendrait-elle la charge ?" par Philippe Beaudouin

    Philippe Beaudoin a utilisé pour cette analyse une combinaison de pgbench (injection), et la table pg_stat_statements qui collecte les statistiques sur l'utilisation mémoire des requêtes : produit une table avec les query, nombre d'appels, temps passé, nombre de lignes, etc.

    L'idée générale est d'établir un profil de charge transactionnel sur la production pour pouvoir comparer avec la pré-production ou la future plateforme.

    Pour éviter de devoir copier les données de production (lent, problème de confidentialité, etc), il est conseillé d'utiliser "generate_series" pour remplir la base de données de données de test.

    pgbench utilise des scenario TPC-B (Transaction Processing Performance Council Benchmarks) Pour chaque scénario (4 scénarios dans son exemple) on a une cible TPS (transaction par secondes). Il recommande de faire attention à ne pas modifier considérablement la taille de la base avec les scénarios (ex. trop de DELETE, ou trop d'INSERTs).

    Un astuce pour charger le cache linux

    find <files> -exec dd if='{}' of=/dev/null\;
    

    Si on ne sait pas quels fichiers charger, on peut utiliser pg_relation_filepath(oid) FROM pg_class where relname like 'tbl%' pour trouver en SQL quels fichiers contiennent les données.

    Nous avons demandé si un outil de type GOR (flux UDP de la production vers la pre-production ou le serveur de développement pour les requêtes HTTP) existait pour Postgresql.

    http://www.logilab.org/file/150448/raw/gor.png

    Réponse : Tsung contient un mode proxy qui permet d'enregistrer la production, ensuite de la rejouer en pre-prod, mais pas en mode live. À priori il serait possible de combiner plusieurs outils existant pour faire cela (pgShark ?). La problématique n'est pas simple notamment lorsque les bases de données divergent (index, series, etc).

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

    PostGIS 2.x et au delà par Hugo Mercier

    Nous avons trouvé la présentation réussie. Elle introduisait les concepts et les nouveautés de PostGIS 2.x. Ayant intégré des fonctionnalités de PostGIS à CubicWeb et travaillant un peu sur la visualisation en WebGL de données stockées dans CubicWeb+Postgresql, nous avons pu réfléchir à des possibilités de délégation de traitement à la base de donnée.

    http://www.logilab.org/file/150441/raw/Screenshot%20from%202013-07-01%2010%3A30%3A00.png

    Nous nous sommes aussi interrogés sur le passage à l'échelle d'applications web qui font de l'affichage de données géographiques, pour éviter d'envoyer au navigateurs un volume de données trop important (geoJSON ou autre). Il y aurait des architectures possible avec une délégation à Postgresql du travail de niveaux de zoom sur des données géographiques.

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


  • Retour Agile Tour Nantes 2012 - présentation et pistes à explorer

    2012/12/04 by Arthur Lutz

    Nous utilisons les méthodes agiles depuis la création de Logilab. Nous avons parfois pris des libertés avec le formalisme des méthodes connues, en adaptant nos pratiques à nos clients et nos particularités. Nous avons en chemin développé nos propres outils orientés vers notre activité de développement logiciel (gestion de version, processus sur les tickets, intégration continue, etc).

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

    Il est parfois bon de se replonger dans la théorie et d'échanger les bonnes pratiques en terme d'agilité. C'est pour cette raison que nous avons participé à l'étape nantaise de l'Agile Tour.

    Logiciels libres et agilité

    Plutôt que d'être simples spectateurs, nous avons présenté nos pratiques agiles, fortement liées au logiciel libre, dont un avantage indéniable est la possibilité offerte à chacun de le modifier pour l'adapter à ses besoins.

    Premièrement, en utilisant la plate-forme web CubicWeb, nous avons pu construire une forge dont nous contrôlons le modèle de données. Les processus de gestion peuvent donc être spécifiques et les données des applications peuvent être étroitement intégrées. Par exemple, bien que la base logicielle soit la même, le circuit de validation des tickets sur l'extranet n'est pas identique à celui de nos forges publiques. Autre exemple, les versions livrées sur l'extranet apparaissent directement dans l'outil intranet de suivi des affaires et de décompte du temps (CRM/ERP).

    Deuxièmement, nous avons choisi mercurial (hg) en grande partie car il est écrit en python ce qui nous a permis de l'intégrer à nos autres outils, mais aussi d'y contribuer (cf evolve).

    Notre présentation est visible sur slideshare :

    http://www.logilab.org/file/113040?vid=download

    ou à télécharger en PDF.

    Behaviour Driven Development

    Le BDD (Behaviour Driven Development) se combine avec des tests fonctionnels haut niveau qui peuvent être décrits grâce à un formalisme syntaxique souvent associé au langage Gherkin. Ces scénarios de test peuvent ensuite être convertis en code et exécutés. Coté Python, nous avons trouvé behave et lettuce. De manière similaire à Selenium (scénarios de test de navigation Web), la difficulté de ce genre de tests est plutôt leur maintenance que l'écriture initiale.

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

    Ce langage haut niveau peut néanmoins être un canal de communication avec un client écrivant des tests. À ce jour, nous avons eu plusieurs clients prenant le temps de faire des fiches de tests que nous "traduisons" ensuite en tests unitaires. Si le client n'est pas forcément prêt à apprendre le Python et leurs tests unitaires, il serait peut-être prêt à écrire des tests selon ce formalisme.


  • Announcing pylint.org

    2012/12/04 by Arthur Lutz

    Pylint - the world renowned Python code static checker - now has a landing page : http://www.pylint.org

    http://www.python.org/images/python-logo.gif

    We've tried to summarize all the things a newcomer should know about pylint. We hope it reflects the diversity of uses and support canals for pylint.

    Open and decentralized Web

    Note that pylint is not hosted on github or another well-known forge, since we firmly believe in a decentralized architecture for the web.

    This applies especially to open source software development. Pylint's development is self-hosted on a forge and its code is version-controlled with mercurial, a distributed version control system (DVCS). Both tools are free software written in python.

    http://www.zjulian.com/wp-content/uploads/2012/05/Centralized-Decentralized-And-Distributed-System.jpg

    We know centralized (and closed source) platforms for managing software projects can make things easier for contributors. We have enabled a mirror on bitbucket (and pylint-brain) so as to ease forks and pull requests. Pull requests can be made there and even from a self-hosted mercurial (with a quick email on the mailing-list).

    Feel free to add your comments or feedback below.


  • OpenData à Nantes: agrégateur des événements culturels

    2011/12/12 by Arthur Lutz

    Jeudi 8 décembre 2011 nous avons participé à la réunion de travail sur l'ouverture des données événementielles.

    Problématique des licences

    Un premier problème est que la licence proposée par LiberTIC est la CreativeCommons CC-BY, alors que les producteurs de données n'ont souvent pas les droits sur toutes les données qu'ils diffusent (par exemple la photo d'illustration d'un concert). Ils auront donc du mal à les publier en totalité sous licence CC-BY. Espérons que la licence Creative Commons rentre dans les habitudes et que cela ne va pas trop freiner le projet.

    Aujourd'hui, l'utilisation ressemble à du Fair Use: on tolère la ré-utilisation de contenus protégés par le droit d'auteur car cela sert la diffusion de l'information.

    Nous nous sommes demandé s'il est possible de mélanger deux licences dans un flux de données ou s'il faut faire deux flux séparés mais liés.

    https://creativecommons.org/images/license-layers.png

    Problématique d'utilisation

    Un deuxième problème est que les réutilisateurs ne seront pas intéréssés si les données sont trop pauvres et qu'elles n'incluent pas d'image ou de vidéo. Il faut donc trouver un socle commun qui satisfasse les producteurs et les réutilisateurs.

    Import ou gros formulaires qui tâchent ?

    Vu la complexité du modèle de données qui a émergé des discussions (beaucoup de cas particuliers), il a été proposé de fournir un formulaire de saisie d'un événement. A notre avis, la saisie "manuelle" doit rester un cas exceptionnel (un acteur culturel n'ayant pas de site pour publier par exemple), au risque de n'être pour les producteurs qu'un enième site à renseigner lors de la publication de son agenda.

    Un exemple de bonnes pratiques est le très populaire GoodRelations qui offre un formulaire pour qu'un utilisateur qui n'a pas intégré le format à sa boutique en ligne puisse facilement générer son fichier et l'héberger chez lui, favorisant ainsi un modèle décentralisé calqué sur celui des moteurs de recherche.

    Formats

    Il nous semble donc important de se concentrer sur les formats standards qui pourraient être importés et exportés par la plateforme.

    En voici une liste non exhaustive:

    Lectures supplémentaires

    Cherchant à combiner des vocabulaires existants (afin de ne pas réinventer un format qui devra être traduit dans un autre vocabulaire pour être réutilisable) nous sommes tombés sur les articles suivants :

    http://cdn1.iconfinder.com/data/icons/transformers/network-connections.png http://cdn1.iconfinder.com/data/icons/transformers/Internet-Explorer.png http://cdn1.iconfinder.com/data/icons/transformers/entire-network.png

    Conclusion

    Il nous paraît important de ne pas se tromper dans les orientations choisies:

    • utiliser des formats standards et combiner l'utilisation de namespaces existants plutôt que d'inventer un nouveau format
    • proposer plusieurs formats d'export pour différentes utilisations (json, ical, etc) quitte à ne pas inclure tout le contenu disponible si le format ne s'y prête pas
    • ne pas créer une API de plus et choisir de privilégier les standards du web sémantique en publiant du RDF et si possible en fournissant un accès SPARQL
    • préférer la publication distribuée des données par leurs producteurs et leur agrégation par la plate-forme plutôt que d'attendre des producteurs qu'ils remplissent un formulaire de plus.

    Nous attendons avec impatience la suite des travaux. Selon LiberTIC la plateforme sera developpée en logiciel libre avec des outils collaboratifs pour piloter le projet.

    CubicWeb est une plateforme disponible en logiciel libre qui a déjà fait ses preuves et a été conçue pour développer des applications du type de l'aggrégateur décrit ci-dessus: import et export des données sous différents formats, utilisation des technologies standards du web sémantique. Nous espérons que ceux qui auront à réaliser l'agrégateur choisiront CubicWeb comme base technique pour ce projet.


  • Rencontre Open Data à Nantes: Enjeux et opportunités pour le secteur culturel

    2011/11/17 by Arthur Lutz

    Nous étions présents à l'évenement organisé par Stereolux et Libertic consacré à l'OpenData dans le domaine de la culture à Nantes. Voici un court compte rendu des points que nous avons retenus de ces présentations.

    Présentation générale de l'OpenData par Libertic

    Il existe sur la toile assez d'articles sur l'Opendata pour qu'il ne nous semble pas nécessaire d'en donner une description, mais nous tenons à souligner que l'OpenData n'est pas simplement une mise à disposition des informations. Pour que des données puissent être qualifiées d'ouvertes, il faut qu'elles respectent une dizaine de principes parmi lesquels l'accessiblité, l'exploitabilité (données brutes), et la la réutilisablitié (licence).

    https://libertic.files.wordpress.com/2010/02/logo-libertic.png?w=300&h=180

    Claire Gallon a cité plusieurs exemples d'OpenData dans le domaine culturel :

    • la mise à disposition de données sur la fréquentation d'un musée permet de développer un service qui donnera la meilleure heure pour visiter ce musée. Voir When Should I visit Tate Modern
    • Marseille-Provence 2013 (capitale culturelle européenne) ouvre ses données et attend que les acteurs écrivent des applications (mobiles notamment).

    Un idée importante est que le service public doit s'adresser au plus grand nombre et ne peut pas consacrer ses ressources à la mise en place de services de niche. La mise à disposition des données permet à des tiers d'occuper ces niches.

    En conclusion, Claire Gallon insiste sur la nécessité d'inclure la gestion de la communauté dans les démarches d'ouverture des données. La prochaine priorité des acteurs de l'OpenData sera la coproduction, à la fois pour l'écriture des applications et pour l'amélioration des données.

    Présentation du projet data.bnf.fr par Romain Wenz

    http://data.bnf.fr/data/logo-bnf.gif http://data.bnf.fr/data/logo-data.gif

    Romain Wenz de la Bibliothèque nationale de France a présenté http://data.bnf.fr sous l'angle de l'ouverture : l'ouverture à un public différent, l'ouverture à un mode de recherche différent (on cherche sur internet avant d'aller en bibliothèque) et l'ouverture sur les reseaux sociaux où le public partage des références à des contenus qu'il apprécie (twitter, facebook, etc.). Cette ouverture passe forcément par un web indexable, où l'on peut communiquer facilement une URL d'un contenu (exit les portails de recherche avec des sessions et variable http). Si un site n'est pas indexable, son contenu pourra être trouvé en s'y connectant directement, mais celui-ci restera dans le web "invisible" ou "profond".

    Romain Wenz a insisté sur l'Importance des technologies utilisées : d'un coté les strandards ouverts et formalisés par le W3C, notamment en terme de web sémantique (RDF, RDFa, opengraph, schema.org, etc.) et de l'autre l'utilité de s'appuyer sur du logiciel libre. Dans le cas de http://data.bnf.fr il s'agit de CubicWeb.

    Présentation des collaborations entre Wikimedia France et des institutions publiques à Toulouse

    https://upload.wikimedia.org/wikipedia/commons/thumb/4/41/Commons-logo-en.svg/75px-Commons-logo-en.svg.png

    La transition entre la BnF et Wikimedia est facile : Wikisource (bibliothèque de livres libres de droits) a signé un partenariat avec Gallica qui lui a fourni des numérisations de livres tombés dans le domaine public.

    Wikimedia France a présenté deux projets réussis en coproduction avec des institutions Toulousaines :

    • le projet Phoebus a donné accès aux archives du Muséum de Toulouse à des bénévoles
    • la communauté Wikimedia Commons a participé à l'enrichissement des metadonnées du fond consacré au photographe Eugène Trutat.

    Présentation OpenData par la mairie de Nantes Métropole

    http://nantes.fr/webdav/site/nantesfr/shared/fileadmin/images/Puces/autrespuces/logo64_queue.png

    Frédéric Vasse a briévement présenté la démarche de la Ville de Nantes en matière d'OpenData. Le lancement de la plateforme aura lieu lundi prochain à la Cantine Numérique de Nantes. Selon lui, l'objectif de Nantes est de réussir la coproduction avec les acteurs du territoire.

    Conclusion et ouverture sur un projet concret d'OpenData pour les acteurs culturels

    Libertic a conclu en proposant aux acteurs culturels un projet d'aggrégateur d'informations sur les événements culturels à Nantes. Nous espérons pouvoir vous donner prochainement plus d'informations sur ce projet.

    Autre compte rendu (prises de notes) : http://www.scribd.com/doc/72810587/Opendata-Culture


  • Pourquoi il faudrait faire du Javascript coté serveur

    2010/10/20 by Arthur Lutz

    Description de la présentation sur le site de Paris Web 2010: ici.

    Quentin Adam voudrait que l'on fasse plus de javascript coté serveur. Un des principaux avantages du javascript server side est que il n'est pas nécessaire de traduire ces structures de données entre plusieurs languages de programmation.

    http://www.bewebmaster.com/bewebmaster/icons/JavaScript.png http://a3.twimg.com/profile_images/90410047/clouds2_normal.jpg

    Une des limites à cette adoption est que les moteurs de javascripts ne font pas de DOM (ca c'est le boulot du navigateur), du coup pas de jquery, mootools ou dojo (high level javascript)>. Par conséquent les développeurs javascript vont avoir des difficultés pour coder en server side. Certaines librairies sont en train de prendre en compte cet environnement limité.

    Quand on fait du javascript coté serveur, on peut considérer les requêtes comme des websockets, ce qui va être avantageux en terme de performances (par exemple lorsque le serveur reçoit deux requêtes identiques, quand la réponse est prête on renvoie deux fois la même chose).

    Voici quelques outils que Quentin Adam recommande ou mentionne :

    • Ape - Ajax Push Engine - http://www.ape-project.org Mettre du javascript dans un module apache. Coté client on a du mootols pour faire du développement.
    • Node.js http://www.nodejs.org très adopté par la communauté ruby. Node.js es apparu au moment de l'émergence de v8. Par contre celui-ci n'est pas très stable, la documentation n'est pas très complète, mais il y a beaucoup de "recettes" sur le web.
    • CommonJS http://www.commonjs.org/ est une librairie qui a l'avantage d'être en cours de standardisation.
    • Jaxer http://jaxer.org/ est une sorte de firefox embarqué dans un module apache, ce qui est un peu trop lourd mais son existence mérite d'être mentionnée.

    À Logilab, pour le développement de CubicWeb, nous penchons plutôt pour les développements des mécanismes asyncrones dans Twisted, mais cette présentation a le mérite de mettre en avant que d'utiliser javascript ne concerne pas uniquement les tweaks dans le navigateur.

    http://twistedmatrix.com/trac/chrome/common/trac_banner.png

  • MiniDebConf Paris 2010

    2010/09/09 by Arthur Lutz
    http://france.debian.net/debian-france.png

    Debian France organise le 30 et 31 octobre prochain une minidebconf à Paris. Le wiki de la conférence est en train de s'étoffer, et pour le moment c'est là qu'il faut s'inscrire. À Logilab nous sommes utilisateurs et contributeurs de Debian, c'est donc naturellement que nous allons essayer d'aller participer à cette conférence. Alexandre Fayolle, développeur Debian ira assister (entre autres) à la présentation de Carl Chenet sur l'état de Python dans Debian.


  • HOWTO install lodgeit pastebin under Debian/Ubuntu

    2010/06/24 by Arthur Lutz

    Lodge it is a simple open source pastebin... and it's written in Python!

    The installation under debian/ubuntu goes as follows:

    sudo apt-get update
    sudo apt-get -uVf install python-imaging python-sqlalchemy python-jinja2 python-pybabel python-werkzeug python-simplejson
    cd local
    hg clone http://dev.pocoo.org/hg/lodgeit-main
    cd lodgeit-main
    vim manage.py
    

    For debian squeeze you have to downgrade python-werkzeug, so get the old version of python-werkzeug from snapshot.debian.org at http://snapshot.debian.org/package/python-werkzeug/0.5.1-1/

    wget http://snapshot.debian.org/archive/debian/20090808T041155Z/pool/main/p/python-werkzeug/python-werkzeug_0.5.1-1_all.deb
    

    Modify the dburi and the SECRET_KEY. And launch application:

    python manage.py runserver
    

    Then off you go configure your apache or lighthttpd.

    An easy (and dirty) way of running it at startup is to add the following command to the www-data crontab

    @reboot cd /tmp/; nohup /usr/bin/python /usr/local/lodgeit-main/manage.py runserver &
    

    This should of course be done in an init script.

    http://rn0.ru/static/help/advanced_features.png

    Hopefully we'll find some time to package this nice webapp for debian/ubuntu.


  • Une mise en place de l’eXtreme Programming - ce que j'en retiens

    2010/05/20 by Arthur Lutz
    http://rubyonrails.org/images/rails.png

    Je suis allé à la présentation de "Une mise en place de l’eXtreme Programming" présenté par Karine Sabatier dans le cadre d'Agile Nantes. On y a parlé plutôt Ruby on Rails que python, mais surtout de méthodes agiles et XP.

    Voici quelques points que j'ai retenu de cette présentation tout à fait pragmatique d'une mise en pratique des principes XP :

    • Le principe de "Convention over configuration" : préférer la convention (notamment pour la programmation) plutôt que la contrainte par la configuration. Dans Ruby On Rails, les conventions sont très fortes, pour faire une application on ne peut pas s'éloigner du modèle MVC : les modèles sont dans "model", les views sont dans "views" etc... À ce sujet, la conférencière a fait référence à deux types de designs que je ne connaissait pas : le DDD Domain-driven Design et Behavior Driven Development.
    • Utilisation de métaphores : trouver un langage commun avec le client mais aussi avec les utilisateurs
    • Application de déploiement ruby on rails : Capistrano, bien qu'à Logilab nous privilégions le déploiement par paquets et dépôts debian, en python on pourra jeter un coup d'œil à Fabric.
    http://retrospectiva.org/extensions/overview/images/product_backlog.png?1265550417
    • Leur projet XP utilisait le logiciel de gestion de projet Retrospectiva. Celui-ci ressemble sur bien des points à JPL (Jeux de Planification Logiciel) disponible sur le framework CubicWeb (http://www.cubicweb.org). Coté intégration continue : CruiseControl , en python nous privilégions apycot.
    • Ce projet a essayé l'utilisation de Selenium pour ces tests web. Le constat est le même que chez Logilab : la première fois que ca marche c'est utile et apporte une grande satisfaction, dans un deuxième temps ca reste très difficile à maintenir. Nous regardons à présent plutôt du coté de Windmill qui a été intégré à la version 3.9 de cubicweb.
    • Une mention a été fait d'une société fonctionnement uniquement en mode agile Pyxis.

  • Enable and disable encrypted swap - Ubuntu

    2010/05/18 by Arthur Lutz
    http://ubuntu-party.org/wp-content/themes/ubuntu-party/scripts/timthumb.php?src=//wp-content/uploads/2010/04/evl-pochette21.png&w=210&h=192&zc=1&q=100

    With the release of Ubuntu Lucid Lynx, the use of an encrypted /home is becoming a pretty common and simple to setup thing. This is good news for privacy reasons obviously. The next step which a lot of users are reluctant to accomplish is the use of an encrypted swap. One of the most obvious reasons is that in most cases it breaks the suspend and hibernate functions.

    Here is a little HOWTO on how to switch from normal swap to encrypted swap and back. That way, when you need a secure laptop (trip to a conference, or situtation with risk of theft) you can active it, and then deactivate it when you're at home for example.

    Turn it on

    That is pretty simple

    sudo ecryptfs-setup-swap
    

    Turn it off

    https://launchpadlibrarian.net/17699584/ecryptfs_64.png

    The idea is to turn off swap, remove the ecryptfs layer, reformat your partition with normal swap and enable it. We use sda5 as an example for the swap partition, please use your own (fdisk -l will tell you which swap partition you are using - or in /etc/crypttab)

    sudo swapoff -a
    sudo cryptsetup remove /dev/mapper/cryptswap1
    sudo vim /etc/crypttab
    *remove the /dev/sda5 line*
    sudo /sbin/mkswap /dev/sda5
    sudo swapon /dev/sda5
    sudo vim /etc/fstab
    *replace /dev/mapper/cryptswap1 with /dev/sda5*
    

    If this is is useful, you can probably stick it in a script to turn on and off... maybe we could get an ecryptfs-unsetup-swap into ecryptfs.


  • Sprint CubicWeb chez Logilab - annonce de dernière minute

    2010/04/29 by Arthur Lutz

    Logilab est en ce moment en train d'acceuillir un sprint autour de la plateforme CubicWeb. L'objectif principal de ce sprint de 5 jours est d'améliorer l'usage de javascript et des css dans CubicWeb :

    http://www.logilab.org/image/28586?vid=download http://codesnip.net/wp-content/uploads/javascript.png
    • avoir une API javascript propre, testée et documentée
    • pouvoir facilement changer le style d'une application cubicweb
    • gestion de bundle pour javascript et CSS
    • une documentation sur les standards d'écriture des fichiers JS et CSS pour cubicweb

    Ce sprint aura lieu du jeudi 29 avril 2010 au 5 mai 2010 (weekend exlus - les bureaux seront fermés). Vous êtes les bienvenus pour contribuer, filer un coup de main, faire du pair programming... ou simplement rencontrer des développeurs cubicweb. Vous pouvez même venir une après-midi ou une seule journée. Pour ceux avec des portables, il y aura du réseau disponible pour être connecté.

    Adresse : 104 Boulevard Auguste-Blanqui, Paris. Sonnez à "Logilab".

    Métro : St Jacques or Corvisart (Glacière est la station la plus proche mais sera fermée à partir de lundi)

    Contact : http://www.logilab.fr/contact

    Dates : du 29/04/2010 au 30/04/2010 et du 03/05/2010 au 05/05/2010


  • L'intégration continue présenté par Agiles Nantes

    2010/03/18 by Arthur Lutz

    Hier, Logilab était à nouveau présent aux rencontres organisées par Agiles Nantes, il s'agissait d'une présentation très fournie sur l'intégration continue (présenté par la société Netapsys). Malheureusement, la principale technologie utilisée était Java dont nous ne sommes pas des grands fans, préférant python. Néanmoins cela donne une bonne idée des possibilités qu'offrent les outils autour du développement java, notamment en terme d'intégration continue (voir Maven, Hudson, Sonar, etc.).

    http://hudson-ci.org/images/butler.png

    On retrouve donc un certain nombre de similarités avec le monde python, notamment avec Artifactory qui reproduit en partie les fonctionnalités de pypi avec easy_install ou buildout ou apt-cacher-ng dans son coté proxy. A Logilab, nous privilégions l'utilisation de paquets debian pour distribuer nos logiciels, ce qui permet, notamment, de ne pas réinventer la roue pour chaque langage de programmation.

    Voici quelques une des notions avancées lors de la présentation qui nous semblent intéressantes sur l'intégration continue :

    • celle-ci permet de mettre en place des environnements de test mis à disposition du client tout le long du projet.
    • cette notion de prototype utilisable en continu doit être présente le plus tôt possible dans un projet.
    • idéalement, un serveur de déploiement/intégration doit être quasiment à l'identique de l'environnement client (utilisation de machines virtuelles)
    • l'intégration continue est souvent plus utilisées par les développeurs et les chefs de projets que par les clients. Mettre en place des rapports utiles au client requiert un soin particulier
    • pour une émulation collective, certaines notations des développeurs sont possible. Par exemple un plugin Hudson donne un point par build réussi, un point par test ajouté, moins dix points pour un build cassé.
    • la visualisation des données peut motiver les développeurs, l'outil Sonar semble être très complet et propose des visualisation assez léchées. A noter, des graphes sur la complexité du code, par classe, par méthode etc. Voir aussi la visualisation de l'arbre des dépendances des librairies avec Radiator.
    http://sonar.codehaus.org/wp-content/themes/sonar/images/dashboard.png

    J'y ai mentionné apycot et buildbot qui sont tous les deux des outils plutôt orientés python (mais pas seulement).

    Pour conclure, tout ça m'a fait penser au concept plus poussé de "Continuous Delivery - BlueGreenDelivery" développé par Martin Fowler, une lecture recommandée pour ceux qui ont déjà pris le pas de l'intégration continue.

    http://www.martinfowler.com/bliki/images/blueGreenDeployment/blue_green_deployments.png

  • Now publishing blog entries under creative commons

    2010/03/15 by Arthur Lutz

    Logilab is proud to announce that the blog entries published on the blogs of http://www.logilab.org and http://www.cubicweb.org are now licensed under a Creative Commons Attribution-Share Alike 2.0 License (check out the footer).

    http://creativecommons.org/images/deed/seal.png

    We often use creative commons licensed photographs to illustrate this blog, and felt that being developers of open source software it was quite logical that some of our content should be published under a similar license. Some of the documentation that we release also uses this license, for example the "Building Salome" documentation. This license footer has been integrated to the cubicweb-blog package that is used to publish our sites (as part of cubicweb-forge).


  • On a fait un tour au Coding Dojo à Nantes

    2010/02/18 by Arthur Lutz

    L'association de promotion des méthodes Agiles sur Nantes et sa région [1] organisait hier soir un "Coding Dojo". C'est une session de codage en public avec des créneaux de 15 minutes par codeur (explication sur codingdojo.org). Le focus de la session était le TDD (Test Driven Developpement).

    http://farm3.static.flickr.com/2509/3947717979_34e5a68d3d_m.jpg

    Annonce de l'événement sur leur site : http://www.agilenantes.org/2010/01/25/coding-dojo-mercredi-17-fevrier-2010/

    Photo par yepyep sous licence creative commons


  • We're happy to host the mercurial Sprint

    2010/02/02 by Arthur Lutz
    http://farm1.static.flickr.com/183/419945378_4ead41a76d_m.jpg

    We're very happy to be hosting the next mercurial sprint in our brand new offices in central Paris. It is quite an honor to be chosen when the other contender was Google.

    So a bunch of mercurial developers are heading out to our offices this coming Friday to sprint for three days on mercurial. We use mercurial a lot here over at Logilab and we also contribute a tool to visualize and manipulate a mercurial repository : hgview.

    To check out the things that we will be working on with the mercurial crew, check out the program of the sprint on their wiki.

    What is a sprint? "A sprint (sometimes called a Code Jam or hack-a-thon) is a short time period (three to five days) during which software developers work on a particular chunk of functionality. "The whole idea is to have a focused group of people make progress by the end of the week," explains Jeff Whatcott" [source]. For geographically distributed open source communities, it is also a way of physically meeting and working in the same room for a period of time.

    Sprinting is a practice that we encourage at Logilab, with CubicWeb we organize as often as possible open sprints, which is an opportunity for users and developers to come and code with us. We even use the sprint format for some internal stuff.

    photo by Sebastian Mary under creative commons licence.


  • New supported repositories for Debian and Ubuntu

    2010/01/21 by Arthur Lutz

    For the release of hgview 1.2.0 in our Karmic Ubuntu repository, we would like to announce that we are now going to generate packages for the following distributions :

    • Debian Lenny (because it's stable)
    • Debian Sid (because it's the dev branch)
    • Ubuntu Hardy (because it has Long Term Support)
    • Ubuntu Karmic (because it's the current stable)
    • Ubuntu Lucid (because it's the next stable) - no repo yet, but soon...
    http://img.generation-nt.com/ubuntulogo_0080000000420571.png

    The old packages in the previously supported architectures are still accessible (etch, jaunty, intrepid), but new versions will not be generated for these repositories. Packages will be coming in as versions get released, if before that you need a package, give us a shout and we'll see what we can do.

    For instructions on how to use the repositories for Ubuntu or Debian, go to the following page : http://www.logilab.org/card/LogilabDebianRepository


  • You can now register on our sites

    2009/09/03 by Arthur Lutz

    With the new version of CubicWeb deployed on our "public" sites, we would like to welcome a new (much awaited) functionality : you can now register directly on our websites. Getting an account with give you access to a bunch of functionalities :

    http://farm1.static.flickr.com/53/148921611_eadce4f5f5_m.jpg
    • registering to a project's activity with get you automated email reports of what is happening on that project
    • you can directly add tickets on projects instead of talking about it on the mailing lists
    • you can bookmark content
    • tag stuff
    • and much more...

    This is also a way of testing out the CubicWeb framework (in this case the forge cube) which you can take home and host yourself (debian recommended). Just click on the "register" link on the top right, or here.

    Photo by wa7son under creative commons.


  • IPMI plugin for Munin python code published

    2009/06/17 by Arthur Lutz
    http://www.logilab.org/image/9368?vid=download

    As you might have noticed we quite like munin. We use it quite a bit to monitor how our servers and services are doing. One of the things we like about munin is obviously that the plugins can be written in python (and perl, bash and ruby).

    On a few recent servers we started playing with IPMI to sensor the temperature, watts, fan's rpms etc. So we went out looking for a munin plugin for that. We found Peter Palfrader's ruby plugins. There was one small glitch though, we came across a simple bug : the "ipmitool -I open sensor" can be real long to execute on certain machines, so configuring the plugin was a bit painful and running it too. Changing the ruby code was a bit tricky since we don't really know ruby... so we did a quick rewrite of the plugin in python... with a few optimizations.

    It's not really complete but works for us, and might be useful to you, so we're publishing the hg repo. You can get the tgz or browse the source.


  • Nous allons à PyConFr 2009

    2009/05/25 by Arthur Lutz

    Le 30 et 31 mai prochain (samedi et dimanche prochain) nous allons être présents à PyConFr édition 2009, nous sommes partenaire de l'évènement et allons y parler de CubicWeb. Pour être plus précis, Nicolas Chauvat y présentera "CubicWeb pour publier DBpedia et OpenLibrary". Il avait déjà évoqué ces sujets sur ce site : Fetching book descriptions and covers et DBpedia 3.2 released.

    Si vous comptez y aller, n'hésitez pas à venir nous dire bonjour.

    http://pycon.fr/images/logo_pyconfr_small.png

  • Almost reached 1000 tickets

    2009/05/13 by Arthur Lutz

    Logilab.org has almost reached a thousand tickets on the Logilab's open source projects. To be exact there are 940 tickets right now. What kind of tickets are they ?

    Here is a quick graph of the state of the tickets in our tracker :

    http://chart.apis.google.com/chart?cht=p&chs=400x200&chd=e:Dc..Iw9EXV&chtt=Logilab.org+tickets+by+state&chl=deprecated%20:%2020|open%20:%20373|rejected%20:%2051|resolved%20:%20358|validated%20:%20136

    Graphing is neat. Maybe soon we'll get this kind of feature automatically in the CubicWeb forge, see this ticket.


  • Venez nous rendre visite à Solution Linux 2009

    2009/03/31 by Arthur Lutz
    http://www.solutionslinux.fr/images/index_07.jpg

    Nous sommes dès ce matin, pendant 3 jours, présents au salon Solutions Linux 2009 au stand du pôle de compétition System@tic dont nous faisons parti. C'est le stand B4/B8, assez prêt de l'entrée sur la gauche (détails).

    Nous allons présenter CubicWeb à plusieurs reprises sur le stand, ainsi que lors des conférences sur le Web2 ce mardi 31 mars de 14h à 17h30 :

    • Adrien présentera "Simile Widgets, des composants de haut niveau pour IHM web"
    • Sylvain présentera "Cubic 3.0 - une plateforme pour les applications web sémantique"

    pour plus de détails consultez le programme.


  • Belier - le ssh par hops

    2009/02/17 by Arthur Lutz

    On vient de découvrir belier qui permet de se connecter facilement à des machines auquelles on doit accéder par des machines ssh intermédiaires. Ca peut s'avérer utile. En plus, c'est en python. En plus, il a fait des paquets debian... et en plus il mentionne pylint. Du coup il mérite mention ici.

    http://www.ohmytux.com/belier/images/schema_belier.png

  • Debian Lenny release date - almost there ?

    2009/02/09 by Arthur Lutz
    http://www.debian.org/logos/openlogo-nd-50.png

    Being big fans of debian, we are impatiently awaiting the new stable release of the distribution : lenny. Finding it pretty difficult to find information about when they were expecting to release it, I asked a colleague if he knew. He's a debian developer so I though he might have the info. And he did : according to the debian.devel mailing list we should be having the release for the 14th of February 2009. In other words : in 5 days!

    http://thread.gmane.org/gmane.linux.debian.devel.announce/1318

    There's a few geeky emails on the release date if you have time to read the threads.

    http://www.sinologic.net/wp-content/uploads/2008/08/lenny_debian.jpg

  • Apycot big version change

    2009/01/26 by Arthur Lutz

    The version convention that we use is pretty straight forward and standard : it's composed of 3 numbers separated by dots. What are the rules to incrementing each on of these numbers ?

    • The last number is a incremented when bugs are corrected
    • The middle number is incremented when stories (functionalities) are implemented to the software
    • The first number is incremented when we have a major change of technology

    Well... if you've been paying attention, apycot just turned 1.0.0, the major change of technology is that it is now integrated to CubicWeb (instead of just generating html files). So for a project in your forge, you describe the apycot configuration for it, and the tests for quality assurance are launched on a regular basis. We're still in the process of stabilizing it (latest right now it 1.0.5), but it already runs on the CubicWeb projects, see the screenshot below :

    http://www.logilab.org/image/7682?vid=download

    You should also know that now apycot has two components : the apycotbot which runs the tests and an cubicweb-apycot which displays the results in cubicweb (download cubicweb-apycot-1.0.5.tar.gz and apycotbot-1.0.5.tar.gz).


  • We're now publishing for Ubuntu aswell

    2009/01/26 by Arthur Lutz
    http://www.ubuntu.com/themes/ubuntu07/images/ubuntulogo.png

    We've always been big fans of debian here at Logilab. So publishing debian packages for our open source software has always been a priority.

    We're now a bit involved with Ubuntu, work with it on some client projects, have a few Ubuntu machines lying around, and we like it too. So we've decided to publish our packages for Ubuntu as well as for debian.

    In the 0.12.1 version of logilab-devtools we introduced publishing of Ubuntu packages with lgp (Logilab Packaging) - see ticket. Since then, you can add the following Ubuntu source to your Ubuntu system

    deb http://ftp.logilab.org/dists hardy/
    

    For now, only hardy is up and running, give us a shout if you want something else!


  • We're open for a chat

    2008/11/25 by Arthur Lutz

    We have a public forum that is accessible both using XMPP (jabber) or IRC.

    Jabber / XMPP

    http://upload.wikimedia.org/wikipedia/commons/thumb/2/21/Jabber-bulb.svg/40px-Jabber-bulb.svg.png

    Our jabber server is jabber.logilab.org.

    If you don't have a jabber account, create one on a server such as jabber.org (here is a list of free jabber services) or use our web based client.

    Once you have a jabber account, come and join us at xmpp://public@conference.jabber.logilab.org

    If you do not know what jabber is, read the wikipedia page about jabber

    IRC / International Relay Chat

    Connect to irc://irc.freenode.net and join #pylint

    If you do not know what irc is, read the wikipedia page about irc.


  • Semantic Roundup - infos glanées au NextMediaCamp

    2008/11/12 by Arthur Lutz
    http://barcamp.org/f/NMC.PNG

    Par manque de temps voici les infos en brut glanées jeudi soir dernier au NextMediaBarCamp :

    Un BarCamp c'est assez rigolo, un peu trop de jeune cadres dynamiques en cravate à mon goût, mais bon. Parmi les trois mini-conférences auxquelles j'ai participé, il y avait une sur le web sémantique. Animée en partie par Fabrice Epelboin qui écrit pour la version française de ReadWriteWeb, j'ai appris des choses. Pour résumer ce que j'y ai compris : le web sémantique il y a deux approches :

    1. soit on pompe le contenu existant et on le transforme en contenu lisible par les machines avec des algorithmes de la mort, comme opencalais le fait (top-down)
    2. soit on écrit nous même en web sémantique avec des microformats ensuite les machines liront de plus en plus le web (bottom-up)
    http://microformats.org/wordpress/wp-content/themes/microformats/img/logo.gif

    Dans le deuxième cas la difficulté est de faciliter la tache des rédacteurs du web pour qu'ils puissent facilement publier du contenu en web sémantique. Pour cela ces outils sont mentionnés : Zemanta, Glue (de la société AdaptiveBlue).

    Tout ça m'a fait penser au fait que si CubicWeb publie déjà en microformats, il lui manque une interface d'édition à la hauteur des enjeux. Par exemple lorsque l'on tape un article et que l'application a les coordonnées d'une personne metionnée, il fait automagiquement une relation à cet élément. A creuser...

    Sinon sur les autres confs et le futur des médias, selon les personnes présentes, c'est assez glauque : des medias publicitaires, custom-made pour le bonheur de l'individu, où l'on met des sous dans les agrégateurs de contenu plutôt sur des journalistes de terrain. Pour ceux que ça intéresse, j'ai aussi découvert lors de ce BarCamp un petit film "rigolo" qui traite ce sujet préoccupant.


  • Using branches in mercurial

    2008/10/14 by Arthur Lutz
    http://www.logilab.org/image/4873?vid=download&small=true

    The more we use mercurial to manage our code repositories, the more we enjoy its extended functionalities. Lately we've been playing and using branches which end up being very useful. We also use hgview instead of the built-in "hg view" command. And its latest release supports the branches functionality, you can filter out the branch you want to look at. Update your installation (apt-get upgrade ?) to enjoy this new functionality... or download it.

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

  • We're going to Europython'08

    2008/07/02 by Arthur Lutz
    http://europython.org/euro/img/europython.png

    Hey,

    We've decided to go to Europython this year. We're obviously going to give a talk about the exciting things we're doing with LAX and GoogleAppEngine. We're on wednesday at midday in the alfa room, check out the schedule here. Since we think it's important that these events take place, we're also chipping in and sponsoring the event.

    We hope to see you there. Drop us a note if you want to meet up.


  • Munin Plugins for Zope

    2008/07/01 by Arthur Lutz
    http://munin-monitoring.org/site/munin.png

    Here at Logilab we find Munin pretty useful. We monitor a lots of machines and a lot of services with it, and it usually gives us pretty useful indicators over time that guide us through to optimizations.

    One of the reasons we adopted this technology is it's modular approach with the plugin architecture. And when we realized we could write plugins in python, we knew we'd like it. After years of using it, we're now actually writing plugins for it. Optimizing zope and zeo servers is not an easy task so we're developping plugins to be able to see the difference between before and after changing things.

    You check out the project here, and download it from the ftp.


  • apycot 0.12.1 released

    2008/06/24 by Arthur Lutz

    After one month of internship at logilab, I'm pleased to announce the 0.12.1 release of apycot.

    for more information read the apycot 0.12.1 release note

    You can also check the new sample configuration.

    Pierre-Yves David


  • SciLab passe en logiciel libre

    2008/06/16 by Arthur Lutz
    http://www.scilab.org/images/homepage/scilab_logo.png

    Bienvenue à SciLab version 5.0 dans le monde du logiciel libre. SciLab 5.0, plateforme open source de calcul scientifique sous licence CeCill, est une alternative crédible et maintenant reconnue comme telle à Matlab. Pour assurer le développement pérenne de Scilab, le consortium Scilab rejoint DIGITEO, parc de recherche d'envergure mondiale dans le domaine des sciences et technologies de l'information en Île-de-France.


  • First version of LAX Book

    2008/06/16 by Arthur Lutz

    Previous documentation was merged into a LAX Book now featuring step-by-step screenshots to get up and running faster.

    http://lax.logilab.org/lax-book

    Don't we all like screenshots...

    http://lax.logilab.org/images/lax-book.08-schema.en.png

    Update: LAX is now included in the CubicWeb semantic web framework.


  • Nouvelle version de LAX - Logilab Appengine eXtension

    2008/06/09 by Arthur Lutz
    http://code.google.com/appengine/images/appengine_lowres.jpg

    La version 0.3.0 de LAX est sortie aujourd'hui voir : http://lax.logilab.org/

    Il suffit de 10 petites minutes pour avoir une application qui tourne, suivez le guide :

    Mise à jour: LAX est maintenant inclus dans CubicWeb.


  • LAX - Logilab Appengine eXtension is a full-featured web application framework running on AppEngine

    2008/06/09 by Arthur Lutz
    http://code.google.com/appengine/images/appengine_lowres.jpg

    LAX version 0.3.0 was released today, see http://lax.logilab.org/

    Get a new application running in ten minutes with the install guide and the tutorial:

    Enjoy!

    Update: LAX is now included in the CubicWeb semantic web framework.


  • New apycot release

    2008/06/02 by Arthur Lutz
    http://www.logilab.org/image/4878?vid=download&small=true

    After almost 2 years of inactivity, here is a new release of apycot the "Automated Pythonic Code Tester". We use it everyday to maintain our software quality, and we hope this tool can help you as well.

    Admittedly it's not trivial to setup, but once it's running you'll be able to count on it. We're working on getting it to work "out-of-the-box"...

    Here's what's in the ChangeLog :

    2008-05-19 -- 0.11.0
    • updated documentation
    • new pylintrc option for the pyhton_lint checker.
    • Added code to disabled checker with missing required option with the proper ERROR statut
    • removed the catalog option of the xml_valid checker this feature can now be handle with the XML_CATALOG_FILE environement variable (see libxml2 doc for details)
    • moved xml tool from python-xml to lxml
    • new 'hourly' mode for running tests
    • new 'test_activity_report' report
    • pylint checker support new disable_msg and show_categories options (show_categories default to Error and Fatal categories to avoid reports polution)
    • activity option "days" has been renamed to "time" and correspond to a number of day in daily mode but to a number of hour in hourly mode
    • fixed debian_lint and debian_piuparts to actually do something...
    • fixed docutils checker for recent docutils versions
    • dropped python 2.2/2.3 compat (to run apycot itself)
    • added output redirectors to the debian preprocessor to avoid parsing errors
    • can use regular expressions in <pp>_match_* options

  • Flying to Google I/O

    2008/05/27 by Arthur Lutz
    http://code.google.com/images/io_logo_sm.gif http://code.google.com/appengine/images/appengine_lowres.jpg

    Three of us from Logilab are going to San Francisco to listen, share and discuss at Google I/O.

    It's a two day developer gathering in San Francisco, with various talks about google technologies : http://code.google.com/events/io/

    We're hoping to show and talk about LAX (http://lax.logilab.org) which uses Google AppEngine


  • Profiter pleinement des CPUs avec Zope/Zeo/Debian

    2008/05/27 by Arthur Lutz

    Voici vite fait comment on profite du quad-core bi-proc multicoeurs avec zope/zeo/pound ... le tout en commandes debian.

    Inspiré de : http://plone.org/documentation/how-to/simple-zope-clustering-with-squid-and-pound

    http://plone.org/documentation/tutorial/introduction-to-the-zodb/zeo%20diagram.png
    • apt-get -uVf install plone-site pound

    • dzhandle -z 2.10 make-zeoinstance sgel_zeo

    • dzhandle -z 2.10 make-instance sgel2 --zeo-server=localhost:8100 -m all

    • dzhandle -z 2.10 make-instance sgel3 --zeo-server=localhost:8100 -m all

    • dzhandle -z 2.10 make-instance sgel1 --zeo-server=localhost:8100 -m all

    • dzhandle -z 2.10 make-instance sgel4 --zeo-server=localhost:8100 -m all

    • modifiez les ports de chaque instance (par exemple 9673, 9674, 9675, 9676)

    • vim ~/zope/instances/sgel*/etc/zope.conf

    • dzhandle add-product sgel1 CMFPlone

    • dzhandle add-product sgel2 CMFPlone

    • dzhandle add-product sgel3 CMFPlone

    • dzhandle add-product sgel4 CMFPlone

    • dzhandle zeoctl sgel_zeo start

    • dzhandle zopectl sgel1 start

    • dzhandle zopectl sgel2 start

    • dzhandle zopectl sgel3 start

    • dzhandle zopectl sgel4 start

    • vim /etc/pound/pound.cfg pour remplacer

      BackEnd
              Address 127.0.0.1
              Port    8080
      End
      

      par

      Service
              BackEnd
                      Address 127.0.0.1
                      Port    9673
              End
              BackEnd
                      Address 127.0.0.1
                      Port    9674
              End
              BackEnd
                      Address 127.0.0.1
                      Port    9675
              End
              BackEnd
                      Address 127.0.0.1
                      Port    9676
              End
      End
      
    • /etc/init.d/pound restart

    • tapez sur http://localhost:8080

    • ajoutez un site plone

    pour tester, lancez htop pour voir l'activité et regardez la différence entre :

    • apt-get -uVf install apache2-utils
    • /usr/sbin/ab -n 100 -c 100 localhost:8080/plone

    et

    • /usr/sbin/ab -n 100 -c 100 localhost:9673/plone

    nice!


  • Reinteract: un outil intéressant pour faire du numpy/scipy

    2008/05/27 by Arthur Lutz

    Il existe un outil, Reinteract, qui permet d'avoir une sorte de d'éditeur/shell Python, où l'on peut aisément modifier et réinterpreter une ligne de code.

    Sachant qu'il sait aussi afficher des plots, etc, il est possible de s'en servir avantageusement pour faire des sessions Matlab-like.

    Je pense donc que c'est un outil à présenter à nos chers apprenants qui sont intéressés par le couple python/numpy comme substitut à Matlab ©®.

    Ex:

    http://fishsoup.net/software/reinteract/reinteract-demo.png

    écrit par David Douard


  • Petit raccourci pratique avec ion3

    2008/05/27 by Arthur Lutz

    Un petit raccourci pratique pour ion3, qui permet, sur la combinaison de touches de son choix, de prendre le texte actuellement sélectionné (surligné) dans sa session X11, et, en fonction de son contenu :

    • d'ouvrir un onglet Firefox avec l'url sélectionnée,
    • d'ouvrir un xpdf si c'est une URL de fichier PDF,
    • lancer OpenOffice.org si c'est un fichier OOo,
    • ouvrir le fichier dans emacs si c'est un .py, .po, etc.
    • etc.

    Pour cela, il faut le script magique ci-dessous, et configurer ion pour appeler ce script sur la bonne combinaison de touches. Par ex. ajouter dans votre ~/.ion3/cfg_ion.lua les lignes

    defbindings("WMPlex.toplevel", {
      bdoc("Automagically view the selected string"),
      kpress(META.."F7",
             "ioncore.exec_on(_, '/home/user/bin/view')"),
    })
    

    Ici, j'ai mappé "Meta+F7", et le script est /home/user/bin/view

    #!/usr/bin/env python
    
    from mimetypes import guess_type
    import sys
    from os.path import abspath
    from os import system, popen
    
    import re
    RGX = re.compile
    
    EMACS = 'emacsclient --no-wait %(uri)s'
    EMACS_WITH_LINE = 'emacsclient --no-wait +%(lineno)s %(uri)s'
    FIREFOX = 'firefox -remote "openURL(%(uri)s, new-tab)"'
    WGET = 'cd /home/adim/tmp && wget %(uri)s & '
    
    commands = [
        ('text/html', FIREFOX),
        ('application/xml', EMACS),
        ('text', EMACS),
        ('image', 'display %(uri)s &'),
        ('application/pdf', 'xpdf %(uri)s &'),
        ('application/postcript', 'gv %(uri)s &'),
        ('application/vnd.sun.xml', 'ooffice %(uri)s &'), # matches writer, impress, etc.
        ('application/vnd.oasis.opendocument', 'ooffice %(uri)s &'),
        ('application/msword', 'ooffice %(uri)s &'),
        ('application/vnd.ms-', 'ooffice %(uri)s &'),
        ]
    
    patterns = [
        (RGX(r'https?://.*?(zip|gz|pdf|ods|doc|odt|ppt|sxw|sxi)$'), WGET),
        (RGX(r'.*(?P<uri>https?://[^ ()]*)( .*)?'), FIREFOX),
        (RGX('.*?\.conf$'), EMACS),
        (RGX('.*?\.po$'), EMACS),
        (RGX('.*?\.xslt$'), EMACS),
        (RGX('.*?\.pot$'), EMACS),
        (RGX(r'\s*F?i?l?e? ?"?(?P<uri>.*?\.py)", line (?P<lineno>\d+)[a-zA-Z_:-]*'), EMACS_WITH_LINE),
        (RGX('.*?(readme|changelog|depends|manifest|makefile)(\.in|\.gz|\.bz2)?$', re.I), EMACS),
        # others might come here ...
        ]
    
    def find_command(selection):
        for rgx, cmd in patterns:
            m = rgx.match(selection)
            if m:
                args = m.groupdict() or {'uri' : selection}
                return cmd, args
        mimetype, encoding = guess_type(selection)
        # XXX: encodings like zip, or gz could be handled
        if mimetype is not None:
            selection = abspath(selection)
            for registered_type, cmd in commands:
                if mimetype.startswith(registered_type):
                    return cmd, {'uri' : selection}
        raise ValueError('nothing matched')
    
    if len(sys.argv)>1:
        selected = ' '.join(sys.argv[1:])
    else:
        selected = popen('xclip -o').read()
    
    if selected:
        try:
            cmd, args = find_command(selected)
        except ValueError:
            # system('wmiijabber error viewing %s' % ' '.join(sys.argv[1:]))
            # XXX print a message in wmii status bar ?
            pass
        else:
            #print "yooo =>", repr(cmd), repr(args)
            system(cmd % args)
    

    Pour que cela fonctionne, il ne faut pas oublier d'installer xclip (sous debian, apt-get install xclip).

    -- écrit par David Douard sur un script de Adrien diMascio


  • Petites astuces de vim

    2008/05/27 by Arthur Lutz

    J'ai découvert vim-addons (qui est apparu dans debian récement) et ce petit outil permet de faire d'etendre les fonctionnalités de vim assez facilement. Voici une utilisation parmi tant d'autres :

    mode gnupg

    pour installer le mode gnupg faites

    vim-addons install gnupg
    

    Ensuite vim pourra ouvrir directement des fichiers encryptés et les réncrypter lorsque vous sauvez. Donc simplement

    vim mot-de-passe-envoyé-par-client.gpg
    

    Voilà, le tour est joué.

    J'avoue que je reste avec emacs pour le code, mais ce genre de petit raccourcis est bien pratique.


  • LAX - Logilab Google AppEngin Sprint at Pycon-FR

    2008/05/20 by Arthur Lutz

    Here are a few pictures from the sprint we organized at Pycon-FR

    We got a few people to install Google AppEngine and LAX on their machines, and explained the concepts at hand to a bunch of other people.

    http://www.logilab.org/image/5002?vid=download

    http://www.logilab.org/image/5003?vid=download

    http://www.logilab.org/image/5005?vid=download

    Update: LAX is now included in the CubicWeb semantic web framework.


  • HOWTO quickly get lax running on linux

    2008/05/19 by Arthur Lutz

    This is how easy it is to get lax to run on your linux machine :

    hg clone http://www.logilab.org/hg/lax/
    wget http://googleappengine.googlecode.com/files/google_appengine_1.0.2.zip
    unzip google_appengine_1.0.2.zip
    ./google_appengine/dev_appserver.py lax/skel/
    

    Point your favorite browser to http://localhost:8080/

    UPDATE: LAX is now included in the CubicWeb semantic web framework.


  • New Logilab.org is launched

    2006/10/24 by Arthur Lutz

    ** Insert announce text here **


  • CMFProjman is being ported to Plone2

    2006/10/18 by Arthur Lutz

    CMFProjman has been asleep for quite a while, and is now being reanimated to work with Plone2. We will release it as soon as we see it's stable.


back to pagination (10 results)