Planète AFPy RSS

[afpyro] AFPyro à Lyon - mercredi 24 juin

Publié le 2015-06-24 00:00:00

Un Afpyro aura lieu le mercredi 24 juin à partir de 19h au Gîte Numérique - 6 rue Saint Georges - 69005 Lyon.

Il n’y aura pas de présentation ce mois ci, nous disucterons de pythoneries en toute tranquillité.

Les participants sont invités à ramener des boissons ou de la nourriture à partager.

Pour se rendre au Gîte Numérique :

  • en métro : arrêt Vieux Lyon - Cathédrale Saint Jean
  • en bus : lignes C20 ou 31 arrêt Saint Georges ou Sala
  • en vélo’v : stations Saint Jean / Cathédrale, Place Crépu

[afpy.org] PyCon-FR 2015 We Want You !

Publié le 2015-06-20 08:32:38
La PyCon-FR 2015 se déroulera donc à Pau du 17 au 20 Octobre à l'E.I.S.T.I

[logilab] Exemple de "contrat agile" mis en place entre Logilab et ses clients

Publié le 2015-06-19 11:41:00

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

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

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

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

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

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

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

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

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

[logilab] Experiments on building a Jenkins CI service with Salt

Publié le 2015-06-17 11:15:00

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

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

Jenkins jobs salt

Core setup: the jenkins formula

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

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

base:
  "jenkins":
    - jenkins
    - jenkins.plugins

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

jenkins:
  lookup:
    - home: /opt/jenkins

Plugins configuration is declared in plugins subsection as follows:

jenkins:
  lookup:
    plugins:
      scm-api:
        url: 'http://updates.jenkins-ci.org/download/plugins/scm-api/0.2/scm-api.hpi'
        hash: 'md5=9574c07bf6bfd02a57b451145c870f0e'
      mercurial:
        url: 'http://updates.jenkins-ci.org/download/plugins/mercurial/1.54/mercurial.hpi'
        hash: 'md5=1b46e2732be31b078001bcc548149fe5'

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

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

Jobs management : the jenkins_jobs formula

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

- scm:
    name: cubicweb
    scm:
      - hg:
         url: http://hg.logilab.org/review/cubicweb
         clean: true

- job:
    name: cubicweb
    display-name: CubicWeb
    scm:
      - cubicweb
    builders:
      - shell: "find . -name 'tmpdb*' -delete"
      - shell: "tox --hashseed noset"
    publishers:
      - email:
          recipients: cubicweb@lists.cubicweb.org

It consists of two parts:

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

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

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

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

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

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

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

jenkins_jobs:
  lookup:
    jobs:
      cubicweb:
        file: <path to local cubicweb.yaml>
        pkgs:
          - mercurial
          - python-dev
          - libgecode-dev

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

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

Outlook

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

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

[sciunto] Python : callback à paramètre unique et passage d'options

Publié le 2015-06-13 22:00:00

Le besoin m'est venu de la bibliothèque pims permettant de charger séquentiellement des images. Typiquement, on fait

frames = pims.ImageSequence('../sample_data/bulk_water/*.png')

Mais si on veut appliquer une fonction appliquant un pré-traitement, on peut ajouter une callback


from skimage.color import rgb2grey 
def preprocess(im):
    """
    callback prenant une image im
    """
    return rgb2grey(im)

frames = pims.ImageSequence('../sample_data/bulk_water/*.png', process_func=preprocess)

Ce qui a pour effet que les images soient en niveau de gris plutôt qu'en RGB. Maintenant, imaginons que ce soit un seuil que je souhaite appliquer

def preprocess(im):
    threshold = 0.8
    grey_im = rgb2grey(im)
    # selectionne les indices satisfaisant la condition
    idx = grey_im < grey_im.max() * threshold
    # applique une transformation
    grey_im[idx] = 0
    return grey_im

L'exemple fonctionne toujours, mais on a un paramètre threshold définit dans la fonction, ce qui n'est pas très flexible si on veut placer cette fonction dans une petite bibliothèque maison. Je préfèrerais la signature suivante :

def preprocess(im, threshold=0.8):

Je vais donc définir dans ma bibliothèque la fonction suivante :

# Je definie une fonction qui prend une fonction et des arguments optionels
def all_args(func, **params):
    # Je definie une fonction qui prend une image
    def wrapper(im):
        # Je retourne ma fonction func avec les bons arguments
        return func(im, **params)
    # je retourne une fonction
    return wrapper

# Je definie ma fonction comme je le souhaite
def preprocess(im, threshold=0.8):
    grey_im = rgb2grey(im)
    idx = grey_im < grey_im.max() * threshold
    grey_im[idx] = 0
    return grey_im

Ainsi je peux faire dans mon code principal

from mabiblio import all_args, preprocess

mythreshold = .36

# je crée une fonction new_preprocess à partir de preprocess, auquel je cache
# le parametre threshold
new_preprocess = all_args(preprocess, threshold=mythreshold)

frames = pims.ImageSequence('../sample_data/bulk_water/*.png', process_func=new_preprocess)

Ici, je peux donc utiliser la fonction preprocess, de manière compacte, un peu partout dans mes codes, sans me soucier de son détail.

Je crois que je dois cette astuce à Thomas Caswell que je remercie.

Liens utiles de sametmax :

[carlchenet] Liens intéressants Journal Du Pirate semaine #24

Publié le 2015-06-11 22:00:10
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 24ème semaine de 2015, 5 liens intéressants que vous avez peut-être ratés, relayés cette semaine par le Journal Du Pirate, votre source d’informations pour le Logiciel Libre francophone ! Swift 2 sera open source Papaye 0.2 est arrivé ! #Python #PyPi Debian 8 :…

[logilab] BestOfWeb 2015

Publié le 2015-06-11 20:01:00

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

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

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

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

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

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

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

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

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

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

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

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

[rcommande] Papaye 0.2 est arrivé !

Publié le 2015-06-06 22:00:00
Cannes - Firework 2014 (Italia), Ludovick sur Flickr

Ça y est! Après de long mois d'attente, j'ai enfin pu sortir une nouvelle release de Papaye ! Pour rappel, c'est une application que je développe depuis quelques temps et qui permet d'avoir un dépôt de paquets Python en local tout en fesant également office de proxy et de cache pour le dépôt PyPI officiel.

Autant dire la vérité, ça n'a pas été de la tarte (à la papaye ...). Je suis parti sur une brique logicielle assez exotique (la ZODB en chef de file) ce qui fait qu' au moindre problème, je me sentais bien seul, Google DuckDuckGo n'était pas toujours d'une grande aide. J'ai notamment été confronté à des problèmes de conflits de transactions et de migrations de données.

Les nouveautés

Un petit mot sur les nouveautés:

  • Une interface web afin de naviguer dans les paquets
  • Un nouveau scheduler pour la gestion des tâches en arrière plan
  • Un système de migrations de données basé sur repoze.evolution (un prochain article sur mon retour d'expérience) et inspiré par South / Alembic

L'application arrive également avec son petit lot de pansements :

  • L'arbre de la base de données ne se déteriore plus dans le temps
  • La configuration de webassets ne pose plus de problème en production
  • Le système de proxy/cache possédait de nombreux bugs. Il a été entièrement réécrit
  • Les paquets ayant des espaces dans leur nom sont correctement pris en charge.

L'interface web

La grosse nouveauté c'est donc l'interface qui permet de naviguer dans les paquets. En voici quelques images:

La page d'accueil:

La page d'accueil

La liste des paquets avec un champs de filtrage:

La liste de paquets

Le détail d'un paquet:

La détail d'un paquet

Pour les utilisateurs d'une des versions précédentes de Papaye, il faudra exécuter une commande suplémentaire afin de migrer/nettoyer votre ancienne base de données

papaye_evolve votre_fichier_de_configuration.ini

Papaye vous obligera de toute façon à exécuter cette commande si vous ne le faites pas.

Au passage, je fais tourner une version "demo" ici: http://papaye.rcommande.org/ (demo/demo pour s'identifier)

La suite

Il reste encore un bout de chemin mais je considère cette version comme la première réellement utilisable et reposant sur des bases solides. La prochaine étape, c'est l'enrichissement de l'interface web avec une interface d'administration pour gérer la base de données (opérations de maintenances), purger le cache des paquets, manipuler le dépôt (édition, suppression, ...) et gérer les utilisateurs. Je vais aussi essayer de travailler sur la documentation, qui est pour le moment...inexistante. La faute à mon anglais très aproximatif.

Et surtout n'hésitez pas à me faire le maximum de retours concernant cette version. Ça se passe toujours sur le dépôt Github

Merci également a Foxmask et Ldgeo pour leurs remontées et corrections !

[AFPy Salt-fr] Annonce : Meetup Salt "Table ronde et Comparaison des frameworks" Salt Ansible Chef Puppet

Publié le 2015-06-04 22:00:00

Le meetup de juin est un peu spécial: nous avons invité des personnes pour défendres les "autres" frameworks. Et oui, la communauté nous demande souvent comment Salt se compare à des frameworks comme Puppet, Chef ou Ansible. Avantages, inconvénients, tailles des ecosystèmes, architecture, nous essayerons d'aborder tous les points qui permettent à chaqun de choisir l'application qui convient à son infrastructure et ses processus.

Le meetup aura lieu à l'école 42 au 96 Boulevard Bessières, Paris, métro Porte de Clichy.

École 42

Voici la liste des intervenants :

Intervenants pour défendre chaque framework

Nous avons prévu un certain nombre de sujets et questions à poser aux intervenants, si vous avez des questions brûlantes, faites nous en part sur la liste, sur IRC (#salt-fr sur freenode) ou sur twitter.

Le meetup est gratuit mais il faut s'inscrire (limité à 100 places) sur meetup.com. Inscrivez vous avant qu'il n'y ait plus de places pour ce meetup un peu exceptionnel !

Comme d'habitude, nous aurons de quoi manger et boire pour continuer les discussion après le débat.

[carlchenet] Liens intéressants Journal Du Pirate semaine #23

Publié le 2015-06-04 22:00:00
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 23ème semaine de 2015, 5 liens intéressants que vous avez peut-être ratés, relayés cette semaine par le Journal Du Pirate, votre source d’informations pour le Logiciel Libre francophone ! Linux : découverte d’un bug sur le système de fichiers EXT4, qui pourrait causer une…

[logilab] KanbanDay 2015

Publié le 2015-06-02 19:34:00

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

Management Visuel

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

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

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

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

/file/293145/raw

Gribouille Académie

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

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

/file/293142/raw

Plénières

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

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

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

/file/293141/raw

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

Autres ressources

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

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

Conclusion

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

[afpyro] AFPyro à Lyon - mercredi 27 mai

Publié le 2015-05-27 00:00:00

Un Afpyro aura lieu le mercredi 27 mai à partir de 19h au Gîte Numérique - 6 rue Saint Georges - 69005 Lyon.

Matthieu nous parlera de son éditeur de texte écrit en Python.

Les participants sont invités à ramener des boissons ou de la nourriture à partager.

Pour se rendre au Gîte Numérique :

  • en métro : arrêt Vieux Lyon - Cathédrale Saint Jean
  • en bus : lignes C20 ou 31 arrêt Saint Georges ou Sala
  • en vélo’v : stations Saint Jean / Cathédrale, Place Crépu

[logilab] Running a local salt-master to orchestrate docker containers

Publié le 2015-05-20 14:45:00

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

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

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

david@perseus:~$ mkdir -p salt/etc/salt
david@perseus:~$ cd salt
david@perseus:~salt/$ cat << EOF >etc/salt/master
interface: 192.168.127.1
user: david

root_dir: /home/david/salt/
pidfile: var/run/salt-master.pid
pki_dir: etc/salt/pki/master
cachedir: var/cache/salt/master
sock_dir: var/run/salt/master

file_roots:
  base:
    - /home/david/salt/states
    - /home/david/salt/formulas/cubicweb

pillar_roots:
  base:
    - /home/david/salt/pillar
EOF

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

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

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

Warning

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

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

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

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

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

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

[logilab] Building Docker containers using Salt

Publié le 2015-05-13 10:51:00

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

Motivation

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

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

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

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

A Dockerfile for the base image

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

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

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

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

Plugin the minion container with the Salt master

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

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

Here:

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

Finally,

salt-key -a docker_minion

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

If all went well, the following command should succeed:

salt 'docker_minion' test.ping

Configuring the container with a Salt formula

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

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

(Optional step, cleanup salt-minion installation.)

Make a snapshot image of your configured container.

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

Try out your new image:

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

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

Make a fully configured image for you service:

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

[sciunto] Don du mois : grammalecte

Publié le 2015-05-02 22:00:00

Ce post s'inscrit dans la série des dons pour vous donner envie de contribuer même très modestement à des logiciels libres. Les petites pierres font les grands édifices (ex de pratiques similaires : 1, 2).

Ce mois-ci, j'ai choisi de donner à grammalecte, une campagne de financement pour un correcteur grammatical. Le montant de ce don est de 5€. Les raisons de ce soutien :

  • développement d'un logiciel libre (comme spécifié ici.
  • utilité grand public évidente
  • fonction serveur qui offira la possibilité d'interfacer avec n'importe quel logiciel et language (latex, markdown...).
  • greffons firefox et thunderbird qui rendront la solution populaire (donc retour d'expérience, donc amélioration à long terme)

Pour donner à grammalecte.

[logilab] Mini-Debconf Lyon 2015

Publié le 2015-04-29 16:52:00
//www.logilab.org/file/291628/raw/debian-france.png

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

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

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

//www.logilab.org/file/291626/raw/juliette.jpg

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

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

//www.logilab.org/file/291627/raw/raphael.jpg

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

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

[cubicweb] Serving Cubicweb via WSGI with Pyramid: comparing the options

Publié le 2015-04-24 18:15:00

CubicWeb can now be powered by Pyramid (thank you so much Christophe) instead of Twisted.

I aim at moving all our applications to CubicWeb/Pyramid, so I wonder what will be the best way to deliver them. For now, we have a setup made of Apache + Varnish + Cubicweb/Twisted. In some applications we have two CubicWeb instances with a naive load balacing managed by Varnish.

When moving to cubicweb-pyramid, there are several options. By default, a cubicweb-pyramid instance started via the cubicweb-ctl pyramid command, is running a waitress wsgi http server. I read it is common to deliver wsgi applications with nginx + uwsgi, but I wanted to play with mongrel2 (that I already tested with Cubicweb a while ago), and give a try to the circus + chaussette stack.

I ran my tests :

  • using ab the simple Apache benchmark tool (aka ApacheBench) ;
  • on a clone of our logilab.org forge ;
  • on my laptop (Intel Core i7, 2.67GHz, quad core, 8Go),
  • using a postgresql 9.1 database server.

Setup

In order to be able to start the application as a wsgi app, a small python script is required. I extracted a small part of the cubicweb-pyramid ccplugin.py file into a elo.py file for this:

appid = 'elo2'

cwconfig = cwcfg.config_for(appid)
application = wsgi_application_from_cwconfig(cwconfig)
repo = cwconfig.repository()
repo.start_looping_tasks()

I tested 5 configurations: twisted, pyramid, mongrel2+wsgid, uwsgi and circus+chaussette. When possible, they were tested with 1 worker and 4 workers.

Legacy Twisted mode

Using good old legacy twisted setup:

cubicwebctl start -D -l info elo

The config setting that worth noting are:

webserver-threadpool-size=6
connections-pool-size=6

Basic Pyramid mode

Using the pyramid command that uses waitress:

cubicwebctl pyramid --no-daemon -l info elo

Mongrel2 + wsgid

I have not been able to use uwsgi-mongrel2 as wsgi backend for mongrel2, since this uwsgi plugin is not provided by the uwsgi debian packages. I've used wsgid instead (sadly, the project appears to be dead).

The mongrel config is:

main = Server(
   uuid="f400bf85-4538-4f7a-8908-67e313d515c2",
   access_log="/logs/access.log",
   error_log="/logs/error.log",
   chroot="./",
   default_host="localhost",
   name="test",
   pid_file="/pid/mongrel2.pid",
   bind_addr="0.0.0.0",
   port=8083,
   hosts = [
       Host(name="localhost",
            routes={'/': Handler(send_spec='tcp://127.0.0.1:5000',
                                 send_ident='2113523d-f5ff-4571-b8da-8bddd3587475',
                                 recv_spec='tcp://127.0.0.1:5001',
                                 recv_ident='')
                   })
           ]
   )

servers = [main]

and the wsgid server is started with:

wsgid --recv tcp://127.0.0.1:5000 --send tcp://127.0.0.1:5001 --keep-alive \
--workers <N> --wsgi-app elo.application --app-path .

uwsgi

The config file used to start uwsgi is:

[uwsgi]
stats = 127.0.0.1:9191
processes = <N>
wsgi-file = elo.py
http = :8085
plugin = http,python
virtualenv = /home/david/hg/grshells/venv/jpl
enable-threads = true
lazy-apps = true

The tricky config option there is lazy-apps which must be set, otherwise the worker processes are forked after loading the cubicweb application, which this later does not support. If you omit this, only one worker will get the requests.

circus + chaussette

For the circus setup, I have used this configuration file:

[circus]
check_delay = 5
endpoint = tcp://127.0.0.1:5555
pubsub_endpoint = tcp://127.0.0.1:5556
stats_endpoint = tcp://127.0.0.1:5557
statsd = True
httpd = True
httpd_host = localhost
httpd_port = 8086

[watcher:webworker]
cmd = /home/david/hg/grshells/venv/jpl/bin/chaussette --fd $(circus.sockets.webapp) elo2.app
use_sockets = True
numprocesses = 4

[env:webworker]
PATH=/home/david/hg/grshells/venv/jpl/bin:/usr/local/bin:/usr/bin:/bin
CW_INSTANCES_DIR=/home/david/hg/grshells/grshell-jpl/etc
PYTHONPATH=/home/david/hg/grshells//grshell-jpl

[socket:webapp]
host = 127.0.0.1
port = 8085

Results

The bench are very simple; 100 requests from 1 worker or 500 requests from 5 concurrent workers, getting the main index page for the application:

One ab worker

ab -n 100 -c 1 http://127.0.0.1:8085/

We get:

Synthesis (1 client)

Response times are:

Response time (1 client)

Five ab workers

ab -n 500 -c 5 http://127.0.0.1:8085/

We get:

Synthesis (5 clients)

Response times are:

Response time (5 clients)

Conclusion

As expected, the legacy (and still default) twisted-based server is the least efficient method to serve a cubicweb application.

When comparing results with only one CubicWeb worker, the pyramid+waitress solution that comes with cubicweb-pyramid is the most efficient, but mongrel2 + wsgid and circus + chaussette solutions mostly have similar performances when only one worker is activated. Surprisingly, the uwsgi solution is significantly less efficient, and especially have some requests that take significantly longer than other solutions (even the legacy twisted-based server).

The price for activating several workers is small (around 3%) but significant when only one client is requesting the application. It is still unclear why.

When there are severel workers requesting the application, it's not a surpsise that solutions with 4 workers behave significanly better (we are still far from a linear response however, roughly a 2x better for 4x the horsepower; maybe the hardware is the main reason for this unexpected non-linear response).

I am quite surprised that uwsgi behaved significantly worse than the 2 other scalable solutions.

Mongrel2 is still very efficient, but sadly the wsgid server I've used for these tests has not been developed for 2 years, and the uwsgi plugin for mongrel2 is not yet available on Debian.

On the other side, I am very pleasantly surprised by circus + chaussette. Circus also comes with some nice features like a nice web dashboard which allows to add or remove workers dynamically:

//www.cubicweb.org/file/5272071/raw//www.cubicweb.org/file/5272077/raw

[afpyro] AFPyro à Lyon - mercredi 22 avril

Publié le 2015-04-22 00:00:00

Un Afpyro aura lieu le mercredi 22 avril à partir de 19h au Gîte Numérique - 6 rue Saint Georges - 69005 Lyon.

Balthazar nous emmène en balade coté backend et nous propose une visite guidée des différents types d’outils communément rencontrés dans le backend d’une application web Python (application et serveur WSGI, serveur web, base de données relationnelles et NoSQL, moteur de recherche, moteur de cache, tâches de fonds, etc...).

Les participants sont invités à ramener des boissons ou de la nourriture à partager.

Pour se rendre au Gîte Numérique :

  • en métro : arrêt Vieux Lyon - Cathédrale Saint Jean
  • en bus : lignes C20 ou 31 arrêt Saint Georges ou Sala
  • en vélo’v : stations Saint Jean / Cathédrale, Place Crépu

Autres liens :

[AFPy Salt-fr] Compte rendu Salt Meetup Paris - avril 2015

Publié le 2015-04-15 22:00:00

Une petite trentaine de membres de la communauté Salt parisienne a été accueilli dans les nouveaux locaux de Tinyclues pour ce meetup. Merci également à Logilab qui a sponsorisé la nourriture.

Nicolas Chauvat PDG de Logilab a annoncé son partenariat avec SaltStack pour assurer la formation, le support et la certification sur Salt en France et en Europe.

Voici un compte rendu rapide des trois présentations de cette soirée.

Interface Web SaltStack Enterprise

Rob Hilberding de SaltStack Inc. qui était à Paris pour plusieurs jours est venu présenter une "pure preview" ce que sera potentiellement l'interface web de la version Enterprise de SaltStack.

Rob de SaltStack

Il a présenté l'interface qu'ils développent, cette dernière s'appuie sur l'API SaltStack et MariaDB ou MySQL. À noter que cette interface n'est qu'une extension, à savoir que la version SalStack Enterprise (master et minion) est basée sur le même code que la version communautaire.

L'interface supporte le multi-master, elle liste les minions et pour chaque minion : elle permet d'avoir l'ensemble de ces grains, le statut de sa connexion et des informations sur les derniers jobs.

La liste des minions pouvant être longue il y a la possibilité de filtrer soit par une correspondance sur une partie de l'ID des minions soit sur la valeur d'un ou plusieurs grains. Un filtre peut permettre la création de groupe de minions, c'est également possible via un wizard dédié. Les groupes créés peuvent être partagés (publics) ou privés. Pour les minions sélectionnés il est possible de lancer un job (depuis une liste). Ainsi cette interface permet à des utilisateurs ne connaissant pas de manière poussé Salt de lancer des actions (job) sur des machines (minions) pour lesquelles ils ont les droits.

Comparaison avec Ansible

Paul Tonelli de Heuritech a présenté les différences entre Ansible et SaltStack qu'il a pu appréhender après une semaine d'utilisation d'Ansible.

  • Ansible utilise SSH pour les communications et donc c'est le serveur qui se connecte aux clients ce qui peut impliquer de paramétrer ssh avec des proxies, le cas typique est l'accès aux serveurs qui sont derrière un HAProxy en mode transparent.
  • Ansible n'a pas de serveur (daemon) qui tourne en continu comme SaltStack, mis à part Tower qui est payant.
  • Tower est une interface Web, qui au delà du fait d'être une GUI, peut offrir des fonctionnalités proches du reactor de Salt.
  • L'approche d'Ansible est d'avoir un playbook par projet alors que Salt a une arborescence pour l'ensemble.
  • Ansible peut cibler un peu comme Salt mais sur des noms de machines et faire des groupes de machines en les déclarant dans un fichier, les wilcards peuvent être utilisés.
  • La gestion des dépendances est simple, il faut que cela soit déclaré avant/au dessus. La conclusion est que Ansible a une approche plus minimaliste et la configuration est plus statique.

Retour d'experience

Joe Bounour de DDN a présenté l'utilisation de Salt dans le cadre du déploiement et maintient des produits de DDN de stockage (type Big data et Object storage). Les produits de DDN déploient des paquets RPMs et produisent une configuration de clusters qui va pousser sur l'ensemble des nœuds (via SSH) les masters et les minions pour déployer toute la stack de cluster management (ZooKeeper, HBase, Hadoop, memcached, etc) afin de surveiller et orchestrer les noeuds. À noter que l’environnement déployé est multi-master, composé au plus de 2 ou 3 masters afin de garantir un service haute disponibilité. DDN a développé un ensemble d'outils (*ctl) qui forment une couche d'abstraction à SaltStack afin de gérer un cluster de nœuds pour des solutions de stockage. Salt est masqué pour le client qui n'a pas besoin de le maîtriser. Salt a été choisi pour sa rapidité, sa parallélisation, sa consistance et son mode multi-master (actif-actif).

Nous avons poursuivi les discussions autour de petits bagels offerts par Logilab.

bagels et companie

[AFPy-Nantes] Le meetup du 28 avril sera un barcamp

Publié le 2015-04-11 22:00:00

La prochaine rencontre Python Nantes sera au format BarCamp et se déroulera le mardi 28 avril, à la Cantine de Nantes.

L'idée est simplement de se retrouver et de décider sur place des sujets de discussions qui vous intéressent, de les aborder ensemble en différents groupes, puis de mettre en commun ce qui s'est dit pendant les ateliers.

Comme toujours ce meetup est ouvert à tous les amoureux ou curieux du langage Python, nous apprécions particulièrement la diversité des profils qui joignent à nous !

Ceux qui ont envie pourront prolonger la soirée autour d'un verre en centre ville de Nantes.

Si vous avez des questions ou des remarques concernant nos meetups, rejoignez-nous sur le chan IRC de l'AFPy Nantes ou inscrivez vous sur la liste de diffusion . Vous pouvez aussi nous suivre sur Twitter via notre compte @PythonNantes :)

À bientôt !

[carlchenet] Liens intéressants Journal Du pirate semaine #15

Publié le 2015-04-09 22:11:31
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 15ème semaine de 2015, 5 liens intéressants que vous avez peut-être ratés, relayés cette semaine par le Journal Du Pirate, votre source d’informations pour le Logiciel Libre francophone ! Proxmox : mise en place de 2 nœuds en Haute disponibilité(HA) Backup Checker 1.7 :…

[AFPy Salt-fr] Annonce : Meetup Salt Paris chez tinyclues - avril 2015

Publié le 2015-04-08 22:00:00

Le meetup d'avril aura lieu dans les locaux de tinyclues au 1 rue du mail 75002, Paris, métro Bourse. Jeudi 16 avril à 19h.

tinyclues

Programme :

  • L'utilisation de la nouvelle feature de chiffrage dans la 2014.7 par Ronan Amicel (Pocket Sensei)
  • Présentation et utilisation de la Salt Mine par Damien DESMARETS (Weborama)
  • Productizing and shipping Salt as a Private Cloud par Samuel Phan (DDN)

Le meetup est gratuit mais il faut s'inscrire (limité à 50 places) sur meetup.com.


View Larger Map

[logilab] Retour sur la journée conteneurs dans le cadre de Open Source Innovation Spring

Publié le 2015-04-07 12:41:00

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.

[carlchenet] Liens intéressants Journal Du pirate semaine #14

Publié le 2015-04-02 22:00:09
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 14ème semaine de 2015, 5 liens intéressants que vous avez peut-être ratés, relayés cette semaine par le Journal Du Pirate, votre source d’informations pour le Logiciel Libre francophone ! Hublin, vidéos et réunions en ligne en mode Libre Hacker les voitures connectées ? C’est…

[carlchenet] Liens intéressants Journal Du pirate semaine #13

Publié le 2015-03-26 23:00:34
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 13ème semaine de 2015, 5 liens intéressants que vous avez peut-être ratés, relayés cette semaine par le Journal Du Pirate, votre source d’informations pour le Logiciel Libre francophone ! Evqueue, un ordonnanceur de tâches libre et open source LDAPS : OpenLDAP et GnuTLS Image…

[carlchenet] On a une sauvegarde de la base de données ? Elle a 6 mois, inutilisable

Publié le 2015-03-25 23:00:37
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Péremption des données Quel informaticien n’a pas été confronté à la péremption des données ? Vos données sont trop vieilles, inutilisables. Les causes peuvent être multiples : schémas des données ayant évolués, format de fichiers incompatibles ou delta trop important avec l’existant. Le cas est particulièrement…

[afpyro] AFPyro à Lyon - mercredi 25 mars

Publié le 2015-03-25 00:00:00

Un Afpyro aura lieu le mercredi 25 mars à partir de 19h au Gîte Numérique - 6 rue Saint Georges - 69005 Lyon.

Une présentation sur apetizer sera donnée par son auteur, et hôte de l’AFPyro, Nicolas Danjean. Apetizer est une librairie pour Django permettant de simplifier la création de vues, APIs, et notamment dans le cadre de création de wizards.

Pour se rendre au Gîte Numérique :

  • en métro : arrêt Vieux Lyon - Cathédrale Saint Jean
  • en bus : lignes C20 ou 31 arrêt Saint Georges ou Sala
  • en vélo’v : stations Saint Jean / Cathédrale, Place Crépu

[carlchenet] Unverified backups are useless. Automatize the controls!

Publié le 2015-03-23 23:00:28
Follow me on Identi.ca  or Twitter  or Diaspora* Unverified backups are useless, every sysadmins know that. But manually verifying a backup means wasting time and resources. Moreover it’s boring. You should automatize it! Backup Checker is a command line software developed in Python 3.4 on GitHub (stars appreciated :) ) allowing users to verify the integrity of…

[carlchenet] Liens intéressants Journal Du pirate semaine #12

Publié le 2015-03-19 23:22:51
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 12ème semaine de 2015, 5 liens intéressants que vous avez peut-être ratés, relayés cette semaine par le Journal Du Pirate, votre source d’informations pour le Logiciel Libre francophone ! Docker Compose remplace Fig Installation d’un cluster de stockage CEPH Censure administrative du Web en…

[sciunto] Don du mois : ipython et jupyter

Publié le 2015-03-19 23:00:00

Ce post s'inscrit dans la série des dons pour vous donner envie de contribuer même très modestement à des logiciels libres. Les petites pierres font les grands édifices.

C'est au tour de Ipython, une interface de type console et web pour python et d'autres langages. Le montant de ce don est de $6. Les raisons de ce soutien :

  • Je l'utilise au quotidien avec Python, notamment pour les notebooks qui me facilite l'analyse et la visualisation de données. Ca a grandement amélioré mon travail.
  • Ipython donne une réelle valeur ajoutée à python par une approche complémentaire pour résoudre un problème. En effet, je n'effectue pas un traitement d'images comme l'écriture d'une bibliothèque logicielle.
  • Ipython a annoncé qu'il allait se découper en deux avec Jupyter, car Ipython gère aussi d'autres langages comme perl ou ruby. C'est donc un projet de très grande ampleur et qui a un fort potentiel.
  • Plusieurs financements viennent aider le développement, ce qui permet d'avoir 6 développeurs à plein temps.
  • L'intégration dans un navigateur en fait une solution facilement auto-hébergeable.

Pour donner à Ipython/Jupyter.

[afpyro] Afpy à Pau le Mercerdi 18 Mars

Publié le 2015-03-18 00:00:00

Un afpyro aura lieu à Pau le 18 Mars à 20h30.

Cela se tiendra au fablab MIPS 4 rue Despourrins au premier étage. (Il faut sonner à l’interphone)

On abordera les générateurs en Python et on causera librement de différents sujets autour de python.

Voir la map

[logilab] De retour du raid agile

Publié le 2015-03-17 12:45:00
https://www.logilab.org/file/288474?vid=download

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

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

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

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

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

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

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

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

[carlchenet] Le Journal Du Pirate : votre source d’informations pour le Logiciel Libre francophone

Publié le 2015-03-11 23:00:21
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca De très bons articles en français sont écrits tous les jours par la communauté francophone du Logiciel Libre, que ce soit via des blogs de passionnés, les sites incontournables de la communauté, les sites ou blogs d’entreprises. Pour s’y retrouver dans ce fourmillement, le Journal Du…

[logilab] Monitoring our websites before we deploy them using Salt

Publié le 2015-03-11 18:23:00

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.

[cubicweb] CubicWeb Roadmap meeting on March 5th 2015

Publié le 2015-03-11 12:30:00

The Logilab team holds a roadmap meeting every two months to plan its CubicWeb development effort. The previous roadmap meeting was in January 2015.

Christophe de Vienne (Unlish) and Aurélien Campéas (self-employed) joined us.

Christophe de Vienne asked for discussions on:

  • Security Context: settle on an approach, and make it happen.
  • Pyramid Cubicweb adoption: where are we? what authentication stack do we want by default?
  • Package layout (aka "develop mode" friendliness): let's get real
  • Documentation: is the restructuration attempt (https://www.cubicweb.org/ticket/4832808) a credible path for the documentation?

Aurélien Campéas asked for discussions on:

  • status of integration in the 3.21 branch
  • a new API for cubicweb stores

Sylvain Thénault asked for discussions on:

  • a new API for dataimport (including cubicweb stores, but not only),
  • new integrators on CW

Versions

Cubicweb

Version 3.18

This version is stable but old and maintained (current is 3.18.8).

Version 3.19

This version is stable and maintained (current is 3.19.9).

Version 3.20

This version is now stable and maintained (current is 3.20.4).

Version 3.21

See below

Agenda

Next roadmap meeting will be held at the beginning of may 2015 at Logilab. Interested parties are invited to get in touch.

Open Discussions

New integrators

Rémi Cardona (rcardona) and Denis Laxaldle (dlaxalde) have now the publish access level on Cubicweb repositories.

Security context

Christophe exposed his proposal for a "security context" in Cubicweb, as exposed in https://lists.cubicweb.org/pipermail/cubicweb/2015-February/002278.html and https://lists.cubicweb.org/pipermail/cubicweb/2015-February/002297.html with a proposition of implementation (see https://www.cubicweb.org/ticket/4919855 )

The idea has been validated based on a substitution variables, which names will start with "ctx:" (the RQL grammar will have to be modified to accept a ":")

This will then allow to write RQL queries like (API still to be tuned):

X owned_by U, U eid %(ctx:cwuser_eid)s

Pyramid

The pyramid-based web server proposed by Christophe and used for its unlish website is still under test and evaluation at Logilab. There are missing features (implemented in cubes) required to be able to deploy pyramid-cubicweb for most of the applications used at Logilab, especially cubicweb-signedrequest

In order to make it possible to implement authentication cubes like cubicweb-signedrequest, the pyramid-cubicweb requires some modifications. These has been developped and are about to be published, along with a new version of signedrequest that provide pyramid compatibility.

There are still some dependencies that lack a proper Debian package, but that should be done in the next few weeks.

In order to properly identify pyramid-related code in a cube, it has been proposed that these code should go in modules in the cube named pviews and pconfig (note that most cube won't require any pyramid specific code). The includeme function should however be in the cube's main packgage (in the __init__.py file)

There have been some discussions about the fact that, for now, a pyramid-cubicweb instance requires an anonymous user/access, which can also be a problem for some application.

Layout

Christophe pointed the fact that the directory/files layout of cubicweb and cubes do not follow current Python's de facto standards, which makes cubicweb hard to use in a context of virtualenv/pip based installation. There is the CWEP004 discussing some aspects of this problem.

The decision has been taken to move toward a Cubicweb ecosystem that is more pip-friendly. This will be done step by step, starting with the dependencies (packages currently living in the logilab "namespace").

Then we will investigate the feasibility of migrating the layout of Cubicweb itself.

Documentation

The new documentation structure has been approved.

It has been proposed (and more or less accepted) to extract the documentation in a dedicated project. This is not a priority, however.

Roadmap for 3.21

No change since last meeting:

  • the complete removal of the dbapi, the merging of Connection and ClientConnection. remains
  • Integrate the pyramid cube to provide the pyramid command if the pyramid framework can be imported: removed (too soon, pyramid-cubicweb's APIs are not stable enough)
  • Integration of CWEP-003 (FROM clause for RQL): removed (will probably never be included unless someone needs it)
  • CWEP-004 (cubes as standard python packages) is being discussed: removed (not for 3.21, see above)

dataimports et stores

A heavy refactoring is under way that concerns data import in CubicWeb. The main goal is to design a single API to be used by the various cubes that accelerate the insertion of data (dataio, massiveimport, fastimport, etc) as well as the internal CWSource and its data feeds.

For details, see the thread on the mailing-list and the patches arriving in the review pipeline.

[carlchenet] Verify your backups… or lose them all

Publié le 2015-03-08 23:00:52
Follow me on Identi.ca  or Twitter  or Diaspora* As a good sysadmin, you thought you had backups for your server but you didn’t verify them before the major migration you attempted? When you need them, they’re empty or full of useless files. And now it’s too late… You won’t guess how often this situation occurs. Backup Checker…

[logilab] A report on the Salt Sprint 2015 in Paris

Publié le 2015-03-06 16:33:00

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

[afpyro] AFPyro à Bruxelles (BE) - vendredi 6 Mars

Publié le 2015-03-06 00:00:00

Un Meetup/AFPyro aura lieu le vendredi 6 Mars à partir de 19h à la Mort Subite - Rue Montagne-aux-Herbes Potagères 7, Brussels.

Pour s’inscrire: http://www.meetup.com/Belgium-Python-Meetup-aka-AperoPythonBe/events/220506641/

En plus des Francophones, des Néerlandophones seront également présents.

Chacun pourra parler sa langue pendant le drink, par contre, les présentations seront en anglais pour être compréhensibles de tous.

Les présentations

  • AI: Curious Actors by Michael
  • Write and prod an efficient REST API with API-Hour in 5 minutes by Ludovic
  • Tool discovery : Plumbum by Fabien
  • Python Belgium Association by Stephane

Prérequis

Pour plus d’intéractions pendant les présentations, vous pouvez venir avec votre laptop, en ayant installé au préalable:

  • wrk si vous voulez essayer de faire tomber le daemon API-Hour de Ludovic
  • plumbum et un serveur distant afin de tester les scripts proposés par Fabien

[sciunto] Don du mois : pitivi

Publié le 2015-03-05 23:00:00

Ce post s'inscrit dans la série des dons pour vous donner envie de contribuer même très modestement à des logiciels libres. Les petites pierres font les grands édifices.

Ce mois-ci (en fait le mois précédent, mais je n'ai pas eu le temps de faire le billet), ce fût pitivi, $5. Pitivi est un logiciel graphique de montage video. Les raisons sont les suivantes :

  • Un logiciel qui a de l'ambition.
  • Il a pour objectif de combler un manque réel dans le logiciel libre et c'est la source d'un reproche que j'entend fréquemment.
  • J'ai pu obtenir de l'aide des devs quand j'ai bêtement raté ma compilation.
  • La campagne n'a pas encore atteint son objectif et elle débloquera des nouvelles fonctionnalités.

Même si je n'utilise pas ce logiciel fréquemment, il m'a rendu quelques services et il est clairement utile selon moi pour les utilisateurs de solutions libres.

Pour donner à pitivi.

[AFPy Salt-fr] Compte rendu du sprint chez Logilab

Publié le 2015-03-05 23:00:00

Juste un petit post pour dire que le sprint sur Salt a rassemblé 7 personnes dans les locaux de Logilab et que nous en avons bien profité et réussi à produire quelques contributions à salt (patches de codes, réflexions sous forme de tickets, etc).

Participants au sprint Salt 2015

Merci à tous les participants d'être venus contribuer et échanger.

Le compte rendu détaillé en anglais est publié sur un blog de Logilab : A report on the Salt Sprint 2015 in Paris

[AFPy-Nantes] Un meetup pour fêter le printemps !

Publié le 2015-03-04 23:00:00

Lors de notre prochain meetup, le 24 mars à 19h à la Cantine, deux sujets très pythoniques vous seront proposés par nos orateurs :

  • Présentation d'asyncio (par Gaël) : La bibliothèque Python 3 asyncio fournit une infrastructure pour écrire du code concurrent mono-threadé en utilisant les coroutines, multiplexer des entrées-sorties à travers des sockets ou d'autres ressources, faire tourner des clients et serveurs réseaux, ...
  • Tests unitaires en python (par Thomas) : Python nous offre par défaut des outils terriblement pratiques pour la mise en place de tests automatisés. Nous aborderons la question de l'utilité et de la pertinence de ces tests unitaires, la mise en oeuvre basique du module unittest. Nous expliquerons ensuite le sujet des fixtures, puis nous irons un peu plus loin, avec le concept de Factory. Enfin, nous présenterons certains modules de tests alternatifs.

Nous espérons vous compter aussi nombreux que d'habitude à ce meetup ainsi qu'au verre qui s'en suivra.

Rejoignez-nous sur le chan IRC de l'AFPy Nantes ou inscrivez vous sur la liste de diffusion . :)

À bientôt !

[afpyro] AFPyro à Lyon - mercredi 25 février

Publié le 2015-02-25 00:00:00

Un Afpyro aura lieu le mercredi 25 février à partir de 19h au Gîte Numérique - 6 rue Saint Georges - 69005 Lyon.

Une présentation sur la programmation multi-agents sera donnée pa Sébastien Floc’h.

Pour se rendre au Gîte Numérique :

  • en métro : arrêt Vieux Lyon - Cathédrale Saint Jean
  • en bus : lignes C20 ou 31 arrêt Saint Georges ou Sala
  • en vélo’v : stations Saint Jean / Cathédrale, Place Crépu

[afpy.org] Un MOOC en français sur Python

Publié le 2015-02-23 11:41:37
Le premier MOOC en français dédié à l'apprentissage du langage Python a été annoncé sur FUN, la plateforme de MOOC du ministère de l’enseignement supérieur.

[AFPy Salt-fr] Sprint Salt en marge de la SaltConf

Publié le 2015-02-18 23:00:00

Que diriez vous de venir faire un petit sprint en marge de la SaltConf (qui a prévu un sprint le mercredi 4 mars 2015 en soirée) dans les locaux de Logilab ? Celui-ci aurait donc lieu le même jour, le mercredi 4 mars, de 9h à 18h.

L'idée est d'avoir une vrai session de travail où l'on finisse la journée avec des contributions à salt (documentation, code, tests, etc). On pourra aussi en profiter pour discuter technique et échanger sur nos pratiques.

En 2013, Logilab avait déjà fait un sprint saltstack, qui malgré des problèmes d'électricité s'était plutôt bien passé.

Pour qu'on puisse savoir le nombre de participants en avance, merci de remplir le framadate (avec possibilité de participer sur IRC, mais bon, c'est pas idéal).

[AFPy Salt-fr] Compte rendu Salt Meetup Paris - février 2015

Publié le 2015-02-15 23:00:00

La communauté Salt française (ou plutôt francilienne) s'est réunie dans les locaux parisiens de Dailymotion pour son premier meetup de l'année, autour de trois présentations. Voici un compte rendu (très court) pour vous renvoyer vers les références.

David Douard

Utiliser salt dans des docker

David Douard de Logilab a fait une rapide présentation sur l'utilisation de salt dans un conteneur docker, par exemple pour tester des configurations salt.

Cette présentation s'est déroulée en deux parties :

  • un présentation rapide de docker
  • une démonstration de l'utilisation de salt dans un docker, avec :
    • la configuration requise pour lancer un salt-master local pour piloter les minions lancés dans des conteneurs,
    • la présentation d'un Dockerfile qui produit une image docker minimal, basée sur une Debian jessie, avec un salt-minion installé et lancé par supervisord,
    • un exemple de test de configuration d'un apt-cacher à partir de la formula existante.

Découper ses states/pillar salt

Paul Tonelli, de Heuritech, nous a fait une présentation sur la bonne manière de sécouper ses states et pillars salt pour installer un salt-master chez un client, et a parlé des bonnes pratiques d'organisation du code salt.

Le support de sa présentation sont disponibles ici.

SaltPad

saltpad

Boris Feld de Tinyclues nous a refait une présentation rapide de son projet saltpad, une interface web pour piloter salt, sous forme d'une démonstration de l'outil.

Discussions

Des discussions se sont engagées suites à ces présentations, notament sur :

  • qui utilise, et comment, les environnements dans une configuration salt,
  • état et stabilité des modules dockerio récement arrivés dans salt,
  • état de la salt-api et utilisation des ACLs

Ces discussions pourraient être le sujet de présentations et de discussions plus avancées lors d'un prochain meetup.

Conclusion

Merci à Dailymotion d'avoir acceuilli et apporté à boire, et fourni les pizzas.

Pour le prochain meetup (avril), votez pour une date sur framadate et n'hésitez pas à inscrire une proposition de présentation ou de lieu sur le pad d'organisation.

[afpyro] Afpy à Pau le mercredi 11 Février

Publié le 2015-02-11 00:00:00

Un afpyro aura lieu à Pau le 11 Février à 20h30.

Cela se tiendra au fablab MIPS 4 rue Despourrins au premier étage. (Il faut sonner à l’interphone)

jpcw nous fera une petite présentation sur les décorateurs en Python et on causera librement de différents sujets autour de python.

Voir la map

[AFPy Salt-fr] Annonce : Meetup Salt Paris chez Dailymotion - Fevrier 2015

Publié le 2015-02-10 23:00:00

Le meetup de février aura lieu dans les locaux de Dailymotion au 140 boulevard Malesherbes, Paris 17e, métro Wagram ou Malesherbes.

Dailymotion

David Douard de Logilab présentera "Faire du Salt dans et avec des docker".

Il reste encore des places pour faire des présentations éclairs. Contactez nous sur la liste pour nous faire une proposition de présentation.

Le meetup est gratuit mais il faut s'inscrire (limité à 50 places) sur meetup.com.


View Larger Map

[AFPy-Nantes] Un petit barcamp ?!

Publié le 2015-02-09 23:00:00

Après les conférences très appréciées du mois de janvier, qui nous ont permis de bien commencer l'année 2015, on continue avec un BarCamp mardi 24 février, encore et toujours à la Cantine !

L'idée sera donc de proposer puis de voter pour quelques thèmes qui deviendront des ateliers / tables rondes, auxquelles tout participant peut s'inscrire, peu importe son niveau de connaissance du sujet. Les différentes discussions pourront donner lieu à des petits compte-rendus afin que toute la communauté profite de ce qui s'est dit ou fait.

Comme d'habitude, ceux qui le souhaitent pourront prolonger l'évènement autour d'un verre en centre ville de Nantes.

Si vous avez des questions ou des remarques concernant nos meetups, rejoignez-nous sur le chan IRC de l'AFPy Nantes ou inscrivez vous sur la liste de diffusion . Vous pouvez aussi nous suivre sur Twitter via notre compte @PythonNantes :)

N'hésitez pas à vous inscrire ici pour que nous ayons un aperçu du nombre de participants : inscription au meetup.

À bientôt !

[raspberry-python] from python import tourism

Publié le 2015-02-06 21:06:00
 Quel est le lien entre Python et le tourisme? On explore le thème sur 3DFutureTech.

Francois
@f_dion

[afpyro] AFPyro à Bruxelles (BE) - le 31 Janvier

Publié le 2015-01-31 00:00:00

Dear Pythonista friends, write down in your agenda the date of the next AFPyro!

The next Aperos Python Belgium will take place on saturday, January 31st in Brussels, during the FOSDEM conference that takes place at ULB from 31st January to 1st February.

In addition to the regulars of AFPyro, we are also pleased to meet the attendees of FOSDEM using Python.

As usual, you can come just for drinking and sharing one (or many) drinks or if you wish, you can also register for the meal that follows, in a near place, at “Chez Léon” for 20:30, rue des Bouchers 18, B-1000 Brussels.

Meeting from 19:45, on first floor of Delirium cafe, Impasse De La Fidélité 4, 1000 Brussels.

If you are a FOSDEM attendee, you can meet us at the Python devroom, after the end of lightning talks, (H.1301 room) to go to Delirium cafe together.

Please sign up in order to book the place: http://doodle.com/ngdeesgbr6dcx3f5

Further information about the next AFPyros in Belgium: Aperos Python Belgium


Amis Pythonistes, notez dans vos agendas la date du prochain AFPyro !

Le prochain Aperos Python Belgium se tiendra le samedi 31 Janvier à Bruxelles, lors du FOSDEM qui se tient à ULB du 31 Janvier au 1 Février.

En plus des habitués de l’AFPyro, nous attendons également avec plaisir les participants du FOSDEM qui utilisent Python.

Comme chaque fois, vous pouvez venir juste pour l’apéro et partager un (ou des) verres, ou si vous le souhaitez, vous inscrire également pour le repas qui suivra, “Chez Léon” à 20h30, rue des Bouchers 18, B-1000 Bruxelles.

Rendez-vous à partir de 19h45, au premier étage du Délirium café, Impasse De La Fidélité 4, 1000 Brussels.

Si vous participez au FOSDEM, nous vous donnons rendez-vous à la salle Python-devroom, après la fin des lightning talks, (salle H.1301), afin d’aller au Délirium café ensemble.

Pour dimensionner au mieux la réservation, merci de vous inscrire sur: http://doodle.com/ngdeesgbr6dcx3f5

Toutes les infos des prochains AFPyros en Belgique: Aperos Python Belgium