Quantcast
Channel: AFPy's Planet
Viewing all 3544 articles
Browse latest View live

[afpyro] AFPyro à Lyon - mardi 16 décembre

$
0
0

Un Afpyro aura lieu le mardi 16 décembre à partir de 20h à l’Antre Autre - 11 rue Terme - 69001 Lyon.

Une présentation sur Sentry sera donnée. Sentry est un logiciel permettant de suivre les erreurs pouvant se produire dans vos applications.

L’Antre Autre est un lieu où nous pouvons discuter autour d’un verre, et, pour ceux qui le souhaitent, prendre un repas.

Pour se rendre à l’Antre Autre :

  • en métro : arrêt Hôtel de Ville
  • en bus : lignes C13 et C18 arrêt Mairie du 1er ou lignes 19, C14 et C3 à l’arrêt Terreaux
  • en vélo’v : stations Place Sathonay, Carmélites Burdeau, Place de la paix

[afpyro] Afpy à Pau le Mercerdi 18 Mars

$
0
0

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] Generate stats from your SaltStack infrastructure

$
0
0

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.

[sciunto] Champ de vitesse dans une mousse

$
0
0

J'ai récemment écrit un petit guide sur le tracking de bulles dans une mousse. A défaut de temps, voici donc un billet court plutôt que rien afin de référencer cette contribution. J'ai utilisé la bibliothèque Trackpy écrite en Python afin de tracker les bulles. Cependant, une étape supplémentaire d'identification a été nécessaire (car en dehors des clous des particules plus classiques) et j'ai utilisé scikit-image.

Le tuto a ainsi pour ambition de montrer la versatilité de trackpy pour des objets moins conventionnels. Il est disponible ici.

[cubicweb] CubicWeb Roadmap meeting on March 5th 2015

$
0
0

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.

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

$
0
0

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.

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

$
0
0
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…

[AFPy Salt-fr] Compte rendu Salt Meetup Paris - novembre 2014

$
0
0

La communauté Salt s'est a nouveau réunie pour son meetup bi-mestriel autour de trois présentations. Voici un compte rendu (très court) pour vous renvoyer vers les références.

Utilisation de salt pour gérer des machines desktop sous windows et mac os.

Aurélien Minet de l'ENS Cachan nous a présenté son utilisation de salt dans la gestion de postes utilisateurs OS X et Windows.

Support de sa présentation

Création de statistiques pour une infrastructure salt

Arthur Lutz de Logilab nous a présenté un développement pour évaluer la distance entre l'état souhaité de son infrastructure salt et l'état réel.

Arthur Lutz

SaltPad

Boris Feld

Boris Feld de tinyclues nous a présenté une interface web pour piloter salt.

Conclusion

Merci à tinyclues d'avoir acceuilli et apporté à boire, ainsi qu'à Logilab pour les pizzas.

Pour le prochain meetup (en janvier), 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.


[sciunto] Champ de vitesse dans une mousse

$
0
0

J'ai récemment écrit un petit guide sur le tracking de bulles dans une mousse. A défaut de temps, voici donc un billet court plutôt que rien afin de référencer cette contribution. J'ai utilisé la bibliothèque Trackpy écrite en Python afin de tracker les bulles. Cependant, une étape supplémentaire d'identification a été nécessaire (car en dehors des clous des particules plus classiques) et j'ai utilisé scikit-image.

Le tuto a ainsi pour ambition de montrer la versatilité de trackpy pour des objets moins conventionnels. Il est disponible ici.

[logilab] Generate stats from your SaltStack infrastructure

$
0
0

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.

[tarek] 5 work week tips

$
0
0

Our Mozilla work week just ended with an amazing evening. We had a private Mackelmore concert. Just check out Twitter with the #mozlandia tag and feel the vibe. example.

When they got on stage I must admit I did not know who Mackelmore was. yeah sorry. I live in a Spotify-curated music world and I have no TV.

At some point they played a song that got me thinking: ooohhh yeah that song, ok.

Anyways.

During some conversations a lot of folks told me that they where overwhelmed by the work week and har a very hard time to keep up with all the events. Some of them were very frustrated and felt like they were completely disconnected.

I went through this a lot in the past but things improved throughout the years. This blog post collect a few tips.

1. List the folks you want to meet

This one is a given. Before you arrive, make a list of the folks you want to meet and the topics you want to talk about with them.

Make that list short. 10, no more.

2. Do not code

This is the worst thing to do: dive into your laptop and code. It's easy to do and time will fly by once you've started to code. People that don't know you well will be afraid of disturbing you.

Coding is not something to do during your work weeks. If you need a break from the crowd that's the next tip.

3. Listen to your body

A work week is intense for your body. By the end of the week you will look like a Zombie and you will not be able to fully enjoy what's happening. If you are coming for a far place, the jetlag is going to make the problem worse. If you're a partygoer that's not going to help either. All the food and drinks are not really helping.

I've seen numerous folks getting really sick on day 3 or 4 because they had intensive days at the beginning of the event. It's hard not to burn out.

Some (young) folks are doing fine on this. I know I am not. What I did for the Portland work week was to skip everything on day 2 starting at 5pm, ate a soup and went to sleep at 8pm. Skipping on all the cookies and beers and goodies gives your body a bit of rest :)

That gave me the energy I needed for day 3.

4. Don't hang with your team all the time

You talk to those folks all the time. Meet other folks, check out other sessions, etc.

This is especially important if your native langage is not English. I got trapped many time by this problem: just hanging with a few french guys.

5. Walk away from meetings

Don't be shy of walking away from meetings that don't bring you any value. Walk out discretly and politely. You are not in a meeting to read hackernews on your laptop. You can do this at home.

People won't get offended in the context of a work week - unless this is a vital team meeting or something.

What are your tips?

[carlchenet] Site comme Hacker News en français : Le Journal Du Pirate

$
0
0
Suivez-moi aussi sur Identi.ca  ou Twitter  ou Diaspora* Avant tout l’adresse du site : Le Journal Du Pirate https://infos.mytux.fr Un site web comme Hacker News mais francophone propulsé par un Logiciel Libre, je trouve que ça manquait à la communauté francophone. C’est maintenant chose faite avec un site dérivé du moteur de Lobste.rs. Les sources…

[AFPy-Nantes] Compte-rendu des conférences : Pélican et (i)Python

$
0
0

Un meetup tardif, dû à la PyConFr, centré sur deux présentations opposées en termes de technicité : une présentation d’un outil (presque) clés-en-mains, et un survol des possibilités de iPython dans la dataviz cartographique, ainsi que quelques bibliothèques utiles.

Pelican : le futur du web vintage

Intervenant : Damien Nicolas, Gordon

Principe

Pelican est un générateur de site statique écrit en Python initialement par Alexis Métaireau.

Le site est réalisé via un langage de template ensuite traduit en HTML. Le contenu généré peut ensuite être déployé sur un serveur sans configuration supplémentaire. Il n’y a donc pas d’applicatif sur le serveur.

Les avantages d’un tel système sont nombreux. D’abord la simplicité. Un simple éditeur de texte suffit pour écrire le contenu. Étant purement textuel, le contenu est facilement versionnable et recevoir/fournir un patch peut se résumer à un envoi de mail. L'absence d’applicatif côté serveur rend la configuration serveur aisée et la sécurité proche de la perfection : pas d’applicatif = pas de faille.

Bon évidemment, il y a quelques inconvénients. En terme de fonctionnalité d’abord, l’absence native de recherche ou de commentaire. Mais heureusement, il est possible via des extensions de remédier à ces problèmes. En revanche, la barrière à l’entrée est immuable. Pour faire du Pelican, il faut pouvoir écrire du RestructuredText ou du Markdown. Pour profiter pleinement de tout ça, il est bon de savoir invoquer une commande “make” ou “git push”. Plus que rébarbatif pour un néophyte.

En pratique

L’installation se fait comme n’importe quelle bibliothèque Python. On crée un environnement virtuel (e.g. via pyvenv en Python 3). On l’active et via pip on peut installer Pelican. A noter que par défaut, Pelican supporte uniquement le RestructuredText pour les articles, pour markdown, il faudra installer le paquet markdown en plus. On peut ensuite préparer le site via l'installer de Pelican, qui de façon interactive pose quelques questions qui facilitent grandement la configuration. A cette étape, on paramètre notamment les différents moyens utiliser pour déployer le site web sur le serveur.

Une fois configuré, on peut écrire des articles. Ces derniers pourront être placés dans un dossier articles dans le dossier content (tout ceci est paramétrable). Pour générer le site, le plus simple est d'utiliser la commande make :

make html

Et on déploie :

make upload

Et la magie opère. Le site est redéployé !

Il est assez facile de tester localement, Pelican permet d’utiliser un simple serveur HTTP en local pour vérifier ses modifications avant de publier des erreurs ;).

Extensions

On l’a écrit, nativement, il n’existe pas de gestion des commentaires ni de fonction de recherche. Rien d’insurmontable cependant.

Commentaires

Pour les commentaires, une solution simple est d’intégrer Disqus. Disqus est un service permettant de stoquer des commentaires sur un autre serveur que celui de l’application. L’extension disqus_static permet d’utiliser l’API de ce service pour gérer les commentaires dans Pelican. Il y a d’autres alternatives, comme par exemple gérer des commentaires statiquement dans des fichiers sur le serveur hébergeant Pelican. Cette dernière solution permet d’éviter les dépendances à un service tiers.

Recherche

Ici, on pourra fait appel à tipue_search, qui permet d’intégrer une fonctionnalité de recherche côté client. Sur le serveur, un fichier JSON est généré. Celui-ci est ensuite utilisé côté client pour de la recherche via JQuery. Le thème elegant intègre cette fonctionnalité nativement.

Autres extensions

Très extensible, il est possible de faire tout un tas de choses avec Pelican. C’est d’ailleurs le moteur utilisé pour le blog que vous lisez en ce moment. Pour vous faire une idée des possibilités, c’est par là : <https://github.com/Python-Nairobi/pelican-plugins>`_.

Les slides de la présentation sont disponibles ici : Pelican

Dataviz avec iPython

Intervenant : Thomas Gratier

IPython est un shell Python interactif offrant autocomplétion et historique des commandes. Il peut également s’utiliser sous forme de notebook dans un navigateur. De nombreuses bibliothèques sont disponibles et peuvent être chargées dynamiquement. Ainsi, il est très aisé de préparer des présentations dynamiques avec démonstration Python en temps réel et image générée directement dans un navigateur. IPython permet aussi de déployer les notebooks sur un site web. C’est donc un outil très puissant à la fois pour expérimenter avec Python mais aussi pour préparer des présentations interactives.

Pas plus de mots, lors du meetup, nous avons pu voir des résultats assez chouettes que vous invités à expérimenter par vous-même ici : Dataviz avec iPython.

Merci à tous pour votre présence et à très bientôt :) !

[tarek] DNS-Based soft releases

$
0
0

Firefox Hello is this cool WebRTC app we've landed in Firefox to let you video chat with friends. You should try it, it's amazing.

My team was in charge of the server side of this project - which consists of a few APIs that keep track of some session information like the list of the rooms and such things.

The project was not hard to scale since the real work is done in the background by Tokbox - who provide all the firewall traversal infrastructure. If you are curious about the reasons we need all those server-side bits for a peer-2-peer technology, this article is great to get the whole picture: http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/

One thing we wanted to avoid is a huge peak of load on our servers on Firefox release day. While we've done a lot of load testing, there are so many interacting services that it's quite hard to be 100% confident. Potentially going from 0 to millions of users in a single day is... scary ? :)

So right now only 10% of our user base sees the Hello button. You can bypass this by tweaking a few prefs, as explained in many places on the web.

This percent is going to be gradually increased so our whole user base can use Hello.

How does it work ?

When you start Firefox, a random number is generated. Then Firefox ask our service for another number. If the generated number is inferior to the number sent by the server, the Hello button is displayed. If is superior, the button is hidden.

Adam Roach proposed to set up an HTTP endpoint on our server to send back the number and after a team meeting I suggested to use a DNS lookup instead.

The reason I wanted to use a DNS server was to rely on a system that's highly available and freaking fast. On the server side all we had to do is to add a new DNS entry and let Firefox do a DNS lookup - yeah you can do DNS lookups in Javascript as long as you are within Gecko.

Due to a DNS limitation we had to move from a TXT field to an A field - which returns an IP field. But converting IP to integer values is not a problem, so that worked out.

See https://wiki.mozilla.org/Loop/Load_Handling#Service_Soft_Start for all the details.

Generalizing the idea

I think using DNS as a distributed database for simple values like this is an awesome idea. I am happy I thought of this one :)

Based on the same technique, you can also set up some A/B testing based on the DNS server ability to send back a different value depending on things like a user location for example.

For example, we could activate a feature in Firefox only for people in Connecticut, or France or Europe.

We had a work week in Portland and we started to brainstorm on how such a service could look like, and if it would be practical from a client-side point of view.

The general feedback I had so far on this is: Hell yeah we want this!

To be continued...

[afpyro] AFPyro à Lyon - mercredi 26 novembre

$
0
0

Un Afpyro aura lieu le mercredi 26 novembre à partir de 19h à l’Antre Autre - 11 rue Terme - 69001 Lyon.

Cet apéro python sera l’occassion de rencontrer à nouveau les gens de l’AFUP/apéro PHP, autour d’une présentation sur Ruby. Ruby est un langage open source qui met l’accent sur la simplicité et la productivité.

L’Antre Autre est un lieu où nous pouvons discuter autour d’un verre, et, pour ceux qui le souhaitent, prendre un repas.

Pour se rendre à l’Antre Autre :

  • en métro : arrêt Hôtel de Ville
  • en bus : lignes C13 et C18 arrêt Mairie du 1er ou lignes 19, C14 et C3 à l’arrêt Terreaux
  • en vélo’v : stations Place Sathonay, Carmélites Burdeau, Place de la paix

[unlish] Nose, coverage, and CubicWeb

$
0
0
CubicWeb
Writing unittests in CubicWeb cubes requires to use pytest, a test runner provided by logilab-devtools. Trying to use an other test runner is problematic, if not doomed to fail, as well as doing code coverage.
Fortunately, we can do something about it.


nose

Using nosetests to run the tests immediately fails with an obscure:
TypeError: unbound method __init__() must be called with SkipAwareTextTestRunner instance as first argument (got TextTestRunner instance instead)

After some digging, I discovered that CubicWebTC, from which we inherit all the test cases, ultimately depends on logilab pytest... which is meant to be a test runner, or so it should.
Logilab pytest, as a runner, introduce features missing from the early versions of unittests. To do so, it monkey-patch unittests itself. And I have a feeling that nose is doing something similar... which leads to the ugly error we have.
The solution is to un-monkey-patch unittests, by including these few lines somewhere loaded before any of the test (we do that in test/__init__.py):
import unittest
save_testrunner = unittest.TextTestRunner

import logilab.common.pytest # noqa
unittest.TextTestRunner = save_testrunner
After that, we can happily use nose to run the cube unittests!

coverage

The Logilab pytest tool is supposed to do code coverage measurement. Thing is: 1) I could not get it working 2) we want to use another test runner.
The naïve approach, using directly coverage or the cover extension of nose (or py.test), unfortunately fails because pytest is still messing with the trace function. The result will invariably be a coverage of 0%.
To avoid CubicWebTC to call any of the tracing-related functions of pytest, we simply inject noop() operations where they are used:
def noop(): pass

import cubicweb.devtools.testlib

cubicweb.devtools.testlib.pause_tracing = noop
cubicweb.devtools.testlib.resume_tracing = noop

And voilà!

In the end, we can use the test runner we want and get coverage to work properly. It remains a hackish workaround though, I think we ultimately need to cut the dependency from CubicWebTC to logilab.devtools.pytest.

[cubicweb] CubicWeb roadmap meeting on November 6th, 2014

$
0
0

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

Here is the report about the November 6th, 2014 meeting. Christophe de Vienne (Unlish) joined us to express their concerns and discuss the future of CubicWeb. Dimitri Papadopoulos (CEA) could not come.

Versions

Version 3.17

This version is stable but old and maintainance will continue only as long as some customers will be willing to pay for it (current is 3.17.17).

If you're still using 3.17, you should go directly to 3.19.

Version 3.18

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

Version 3.19

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

Version 3.20

This version is still under development but should be released very soon now (expected next week). Its main feature being the inclusion of CWEP-002 (computed attributes and relations), along with many small improvement patches.

For details read list of tickets for CubicWeb 3.20.0.

We would have loved to integrate the pyramid cube in this release, but the debian packaging effort needed by the pyramid stack is quite big and is acceptable if we target jessie only (at decent price).

Version 3.21

For now, the roadmap for 3.21 is still the complete removal of the dbapi, the merging of Connection and ClientConnection, and possibly including CWEP-003 (adding a FROM clause to RQL).

Integrate the pyramid cube to provide the pyramid command if the pyramid framework can be imported.

Integration of CWEP-004 is being discussed.

Version 4.0

We expect to accelerate development of CubicWeb 4, which exact roadmap is still to be discussed, but we may already want:

  • be pyramid-based (remove twisted, auth management, etc.),
  • do not have anything left of old dbapi and ClientConnection,
  • integrate squareui as main (and only) web-ui "template" or remove web generation (almost) completely from cubicweb-core and provide it only through the cube system.

CWEPs

Here is the status of open CubicWeb Evolution Proposals:

to be written

Work in progress

Some work is in progress around CKAN, DCAT and othr Open Data and Semantic Web related technologies.

Agenda

Next roadmap meeting will be held at the beginning of january 2015 at Logilab, and Christophe and Dimitri (or Yann) are invited.

Open Discussions

Migration:

  • AppObjects should not be loaded by default
  • Have a look at Alembic the migration tool for SQLAlchemy and take inspiration from there

[logilab] De retour du raid agile

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

[logilab] PyconFR 2014 : jour 1, bus de communication, packaging et fin

$
0
0

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

[logilab] PyconFR 2014 : jour 1, frameworks web et gestion de source

$
0
0

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

Viewing all 3544 articles
Browse latest View live