Planète AFPy RSS

[cubicweb] Introducing cubicweb-jsonschema

Publié le 2017-03-23 09:57:00

This is the first post of a series introducing the cubicweb-jsonschema project that is currently under development at Logilab. In this post, I'll first introduce the general goals of the project and then present in more details two aspects about data models (the connection between Yams and JSON schema in particular) and the basic features of the API. This post does not always present how things work in the current implementation but rather how they should.

Goals of cubicweb-jsonschema

From a high level point of view, cubicweb-jsonschema addresses mainly two interconnected aspects. One related to modelling for client-side development of user interfaces to CubicWeb applications while the other one concerns the HTTP API.

As far as modelling is concerned, cubicweb-jsonschema essentially aims at providing a transformation mechanism between a Yams schema and JSON Schema that is both automatic and extensible. This means that we can ultimately expect that Yams definitions alone would sufficient to have generated JSON schema definitions that would consistent enough to build an UI, pretty much as it is currently with the automatic web UI in CubicWeb. A corollary of this goal is that we want JSON schema definitions to match their context of usage, meaning that a JSON schema definition would not be the same in the context of viewing, editing or relationships manipulations.

In terms of API, cubicweb-jsonschema essentially aims at providing an HTTP API to manipulate entities based on their JSON Schema definitions.

Finally, the ultimate goal is to expose an hypermedia API for a CubicWeb application in order to be able to ultimately build an intelligent client. For this we'll build upon the JSON Hyper-Schema specification. This aspect will be discussed in a later post.

Basic usage as an HTTP API library

Consider a simple case where one wants to manipulate entities of type Author described by the following Yams schema definition:

class Author(EntityType):
    name = String(required=True)

With cubicweb-jsonschema one can get JSON Schema for this entity type in at different contexts such: view, creation or edition. For instance:

  • in a view context, the JSON Schema will be:

    {
        "$ref": "#/definitions/Author",
        "definitions": {
            "Author": {
                "additionalProperties": false,
                "properties": {
                    "name": {
                        "title": "name",
                        "type": "string"
                    }
                },
                "title": "Author",
                "type": "object"
            }
        }
    }
    
  • whereas in creation context, it'll be:

    {
        "$ref": "#/definitions/Author",
        "definitions": {
            "Author": {
                "additionalProperties": false,
                "properties": {
                    "name": {
                        "title": "name",
                        "type": "string"
                    }
                },
                "required": [
                    "name"
                ],
                "title": "Author",
                "type": "object"
            }
        }
    }
    

    (notice, the required keyword listing name property).

Such JSON Schema definitions are automatically generated from Yams definitions. In addition, cubicweb-jsonschema exposes some endpoints for basic CRUD operations on resources through an HTTP (JSON) API. From the client point of view, requests on these endpoints are of course expected to match JSON Schema definitions. Some examples:

Get an author resource:

GET /author/855
Accept:application/json

HTTP/1.1 200 OK
Content-Type: application/json
{"name": "Ernest Hemingway"}

Update an author:

PATCH /author/855
Accept:application/json
Content-Type: application/json
{"name": "Ernest Miller Hemingway"}

HTTP/1.1 200 OK
Location: /author/855/
Content-Type: application/json
{"name": "Ernest Miller Hemingway"}

Create an author:

POST /author
Accept:application/json
Content-Type: application/json
{"name": "Victor Hugo"}

HTTP/1.1 201 Created
Content-Type: application/json
Location: /Author/858
{"name": "Victor Hugo"}

Delete an author:

DELETE /author/858

HTTP/1.1 204 No Content

Now if the client sends invalid input with respect to the schema, they'll get an error:

(We provide a wrong born property in request body.)

PATCH /author/855
Accept:application/json
Content-Type: application/json
{"born": "1899-07-21"}

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
    "errors": [
        {
            "details": "Additional properties are not allowed ('born' was unexpected)",
            "status": 422
        }
    ]
}

From Yams model to JSON Schema definitions

The example above illustrates automatic generation of JSON Schema documents based on Yams schema definitions. These documents are expected to help developping views and forms for a web client. Clearly, we expect that cubicweb-jsonschema serves JSON Schema documents for viewing and editing entities as cubicweb.web serves HTML documents for the same purposes. The underlying logic for JSON Schema generation is currently heavily inspired by the logic of primary view and automatic entity form as they exists in cubicweb.web.views. That is: the Yams schema is introspected to determine how properties should be generated and any additionnal control over this can be performed through uicfg declarations [1].

To illustrate let's consider the following schema definitions which:

class Book(EntityType):
    title = String(required=True)
    publication_date = Datetime(required=True)

class Illustration(EntityType):
    data = Bytes(required=True)

class illustrates(RelationDefinition):
    subject = 'Illustration'
    object = 'Book'
    cardinality = '1*'
    composite = 'object'
    inlined = True

class Author(EntityType):
    name = String(required=True)

class author(RelationDefinition):
    subject = 'Book'
    object = 'Author'
    cardinality = '1*'

class Topic(EntityType):
    name = String(required=True)

class topics(RelationDefinition):
    subject = 'Book'
    object = 'Topic'
    cardinality = '**'

and consider, as before, JSON Schema documents in different contexts for the the Book entity type:

  • in view context:

    {
        "$ref": "#/definitions/Book",
        "definitions": {
            "Book": {
                "additionalProperties": false,
                "properties": {
                    "author": {
                        "items": {
                            "type": "string"
                        },
                        "title": "author",
                        "type": "array"
                    },
                    "publication_date": {
                        "format": "date-time",
                        "title": "publication_date",
                        "type": "string"
                    },
                    "title": {
                        "title": "title",
                        "type": "string"
                    },
                    "topics": {
                        "items": {
                            "type": "string"
                        },
                        "title": "topics",
                        "type": "array"
                    }
                },
                "title": "Book",
                "type": "object"
            }
        }
    }
    

    We have a single Book definition in this document, in which we find attributes defined in the Yams schema (title and publication_date). We also find the two relations where Book is involved: topics and author, both appearing as a single array of "string" items. The author relationship appears like that because it is mandatory but not composite. On the other hand, the topics relationship has the following uicfg rule:

    uicfg.primaryview_section.tag_subject_of(('Book', 'topics', '*'), 'attributes')
    

    so that it's definition appears embedded in the document of Book definition.

    A typical JSON representation of a Book entity would be:

    {
        "author": [
            "Ernest Miller Hemingway"
        ],
        "title": "The Old Man and the Sea",
        "topics": [
            "sword fish",
            "cuba"
        ]
    }
    
  • in creation context:

    {
        "$ref": "#/definitions/Book",
        "definitions": {
            "Book": {
                "additionalProperties": false,
                "properties": {
                    "author": {
                        "items": {
                            "oneOf": [
                                {
                                    "enum": [
                                        "855"
                                    ],
                                    "title": "Ernest Miller Hemingway"
                                },
                                {
                                    "enum": [
                                        "857"
                                    ],
                                    "title": "Victor Hugo"
                                }
                            ],
                            "type": "string"
                        },
                        "maxItems": 1,
                        "minItems": 1,
                        "title": "author",
                        "type": "array"
                    },
                    "publication_date": {
                        "format": "date-time",
                        "title": "publication_date",
                        "type": "string"
                    },
                    "title": {
                        "title": "title",
                        "type": "string"
                    }
                },
                "required": [
                    "title",
                    "publication_date"
                ],
                "title": "Book",
                "type": "object"
            }
        }
    }
    

    notice the differences, we now only have attributes and required relationships (author) in this schema and we have the required listing mandatory attributes; the author property is represented as an array which items consist of pre-existing objects of the author relationship (namely Author entities).

    Now assume we add the following uicfg declaration:

    uicfg.autoform_section.tag_object_of(('*', 'illustrates', 'Book'), 'main', 'inlined')
    

    the JSON Schema for creation context will be:

    {
        "$ref": "#/definitions/Book",
        "definitions": {
            "Book": {
                "additionalProperties": false,
                "properties": {
                    "author": {
                        "items": {
                            "oneOf": [
                                {
                                    "enum": [
                                        "855"
                                    ],
                                    "title": "Ernest Miller Hemingway"
                                },
                                {
                                    "enum": [
                                        "857"
                                    ],
                                    "title": "Victor Hugo"
                                }
                            ],
                            "type": "string"
                        },
                        "maxItems": 1,
                        "minItems": 1,
                        "title": "author",
                        "type": "array"
                    },
                    "illustrates": {
                        "items": {
                            "$ref": "#/definitions/Illustration"
                        },
                        "title": "illustrates_object",
                        "type": "array"
                    },
                    "publication_date": {
                        "format": "date-time",
                        "title": "publication_date",
                        "type": "string"
                    },
                    "title": {
                        "title": "title",
                        "type": "string"
                    }
                },
                "required": [
                    "title",
                    "publication_date"
                ],
                "title": "Book",
                "type": "object"
            },
            "Illustration": {
                "additionalProperties": false,
                "properties": {
                    "data": {
                        "format": "data-url",
                        "title": "data",
                        "type": "string"
                    }
                },
                "required": [
                    "data"
                ],
                "title": "Illustration",
                "type": "object"
            }
        }
    }
    

    We now have an additional illustrates property modelled as an array of #/definitions/Illustration, the later also added the the document as an additional definition entry.

Conclusion

This post illustrated how a basic (CRUD) HTTP API based on JSON Schema could be build for a CubicWeb application using cubicweb-jsonschema. We have seen a couple of details on JSON Schema generation and how it can be controlled. Feel free to comment and provide feedback on this feature set as well as open the discussion with more use cases.

Next time, we'll discuss how hypermedia controls can be added the HTTP API that cubicweb-jsonschema provides.

[1]this choice is essentially driven by simplicity and conformance when the existing behavior to help migration of existing applications.

[Yaal] Un an de commits

Publié le 2017-03-21 23:00:00

Les logiciels et les services web évoluent au fil du temps, selon les redéfinitions des besoins utilisateurs, l'émergence de nouveaux besoins, l'adaptation à de nouveaux marchés, etc.

Pour cela, le code source est modifié et complété. Il faut modifier l'existant, au minimum pour insérer le nouveau code. Le plus souvent, il s'agit de raffiner l'existant et donc principalement faire des modifications. L'exemple suivant montre un an d'évolution du code sur un projet existant depuis quelques années, sur lequel plusieurs personnes travaillent au quotidien. La quantité d'évolution montre les lignes de code ajoutées, modifiées et supprimées :

En valeur absolue

Graphique du nombre d'ajout, de modification et de suppression de lignes de code par jour

En part relative

Graphique du nombre d'ajout, de modification et de suppression de lignes de code par jour

Le graphique montre bien le fait les programmeurs passent surtout du temps à relire le code existant et le faire évoluer plutôt que d'écrire des pans entiers à partir d'une feuille vierge. D'où l'importance d'avoir un code source simple et lisible.

Les projets grossissent au fil du temps puisqu'il faut surtout modifier et ajouter des nouveautés. Supprimer des fonctionnalités n'arrive quasiment jamais. Les principales opportunités pour enlever du code sont donc :

  • la factorisation : supprimer des duplications de code source
  • l'externalisation : remplacer du code spécifique au projet pour le remplacer par une bibliothèque, un framework, etc.

NB : les données proviennent d'un projet existant depuis quelques années, sur lequel plusieurs personnes travaillent au quotidien.

[Yaal] Yaal recherche un.e développeu.r.se Fullstack

Publié le 2017-03-13 23:00:00

Yaal cherche un|e développeu|r|se pour agrandir son équipe ! #TDD #Python #Linux #ES6 #extremeprogramming

[ascendances] Faker : une bibliothèque python pour générer des noms aléatoirement

Publié le 2017-03-12 11:28:18
Faker est une bibliothèque python pour générer aléatoirement des noms, adresses, etc. Elle facilite l’écriture de script pour remplir une base de données avec de fausses informations diversifiées. Les données produites peuvent être en français. Comme ça, vous pourrez avoir Bertrand Picard plutôt que Lisa Smith. L’anglais est la langue par défaut mais il est […]

[ascendances] Et pour quelques elif de plus

Publié le 2017-01-26 13:21:08
Face à une succession de if-elif-elif-elif-… longue comme un générique de film, il peut être tentant de les remplacer par un switch-case comme on peut en voir en C, PHP, Java, etc. C’est simplement impossible en Python car cette instruction n’existe pas. Plusieurs propositions pour l’inclure dans le langage ont été faites mais elles ont […]

[Yaal] PyConFr 2016

Publié le 2016-11-28 23:00:00

Comme tous les ans depuis 2013, Yaal a sponsorisé la PyConFr 2016. Arthur, Pierre, Stéphane et moi-même nous sommes rendus cette année à Rennes pour participer à l’événement.

Logo PyConFr 2016

Nous avons eu l’occasion de partager de bons moments avec la communauté Python francophone, mais également quelques intervenants internationaux. Je pense notamment à Ipsha Bhidonia qui nous a présenté les Web Push Notifications et nous fait part de son retour d’expérience sur son blog.

Nous en profitons également pour remercier tous les intervenants qui au cours de ces quatre jours ont contribué à différent projets dans les sprints et présentés des conférences de qualité dont les vidéos sont disponibles en ligne.

Yaal a également pris part à ces conférences grâce à Pierre et sa présentation Test Tout Terrain, encourageant les non-initiés à faire leurs premiers pas vers les tests en python (vidéo disponible ici) et Stéphane avec son lighning talk sur MarkdownMail, un outils créé par Yaal et disponible sur pypi.

Le développement par le test est une pratique que nous affectionnons particulièrement chez Yaal. Nous souhaitons donc mentionner Boris Feld qui a également prêché la bonne parole avec sa présentation Python testing 101.

Nous sommes également très heureux d’avoir pu échanger avec Alexis Métaireau, créateur de Pelican, un générateur de site statique que nous utilisons pour le blog de Yaal, Stéphane Wirtel, contributeur de Python 3.6, Arthur Vuillard de l’AFPY (Association Francophone de Python) et David Nowinsky (je vous invite à lire son article de blog). Vous pouvez également jeter un œil à l’article d’Alex Marandon et à la présentation de Florian Strzelecki sur la lecture et l’écriture de documentation !

Pour finir nous souhaitons remercier tous les organisateurs et bénévoles qui ont rendu cette PyConFr 2016 possible. En espérant vous recroiser l’an prochain !

Photo participants PyConFr 2016 Photo de Rémi Martin, source

[afpyro] AFPYro à Pau - Mardi 25 octobre

Publié le 2016-10-25 00:00:00

Viendez, viendez donc à cet AFPYro consacré à Django au mips-lab à 18h30.

Suite au succès du 18, Cédric continue son initiation à Django.

MIPS-LAB
4, rue Despourrins
64000 Pau
France

[j-mad] Pyconfr au pays des galettes saucisses !

Publié le 2016-10-19 23:24:21
Ce week-end (enfin en vrai depuis jeudi si on compte les sprints) c’était donc le week-end de la Pyconfr. Et c’était à Rennes. Je ne dis pas ça comme un reproche, même si je nierais l’avoir écrit, j’aime plutôt bien Rennes. Bon d’accord il pleut tout le temps et il semblerait qu’un certains nombre de [...]

[afpyro] AFPYro à Pau - Mardi 18 octobre

Publié le 2016-10-18 00:00:00

Viendez, viendez à cet AFPYro post-pycon au mips-lab à 18h30

Cédric y présentera Django

MIPS-LAB
4, rue Despourrins
64000 Pau
France

[raspberry-python] Something For Your Mind, Polymath Podcast episode 2

Publié le 2016-10-05 18:25:00

A is for Anomaly

In this episode, "A is for Anomaly", our first of the alphabetical episodes, we cover financial fraud, the Roman quaestores, outliers, PDFs and EKGs. Bleep... Bleep... Bleep...
"so perhaps this is not the ideal way of keeping track of 15 individuals..."

Something for your mind is available on



art·chiv.es

/'ärt,kīv/



Francois Dion
@f_dion
P.S. There is a bit more detail on this podcast as a whole, on linkedin.

[AFPy-Nantes] Annonce meetup du mois de octobre 2016 : les tests en python

Publié le 2016-10-04 22:00:00

La prochaine rencontre Python Nantes sera au format Présentations et se déroulera le mercredi 5 ocotbre de 19h à 21h, à la Cantine de Nantes.

Au programme :

  • introduction aux tests unittaires
  • lancer les tests : unittest de base, py.test, nose, pytest, etc.
  • tox pour lancer les test dans des virtualenvs
  • l'intégration continue avec python (jenkins, travis, etc.)
  • les tests en prod : healthchecks au cœur de l'application

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.

Le meetup est gratuit mais il faut s'inscrire sur http://www.meetup.com/Nantes-Python-Meetup/events/233581812/.

À bientôt !

[raspberry-python] Something for your mind: Polymath Podcast Episode 001

Publié le 2016-09-25 23:32:00

Two topics will be covered:

Chipmusic, limitations and creativity

Numfocus (Open code = better science)


The numfocus interview was recorded at PyData Carolinas 2016. There will be a future episode covering the keynotes, tutorials, talks and lightning talks later this year. This interview was really more about open source and less about PyData.

The episode concludes with Learn more, on Claude Shannon and Harry Nyquist.

Something for your mind is available on

art·chiv.es
/'ärt,kīv/



Francois Dion
@f_dion

[cubicweb] Monitor all the things! ... and early too!

Publié le 2016-09-16 11:34:00

Following the "release often, release early" mantra, I thought it might be a good idea to apply it to monitoring on one of our client projects. So right from the demo stage where we deliver a new version every few weeks (and sometimes every few days), we setup some monitoring.

https://www.cubicweb.org/file/15338085/raw/66511658.jpg

Monitoring performance

The project is an application built with the CubicWeb platform, with some ElasticSearch for indexing and searching. As with any complex stack, there are a great number of places where one could monitor performance metrics.

https://www.cubicweb.org/file/15338628/raw/Screenshot_2016-09-16_12-19-21.png

Here are a few things we have decided to monitor, and with what tools.

Monitoring CubicWeb

To monitor our running Python code, we have decided to use statsd, since it is already built into CubicWeb's core. Out of the box, you can configure a statsd server address in your all-in-one.conf configuration. That will send out some timing statistics about some core functions.

The statsd server (there a numerous implementations, we use a simple one : python-pystatsd) gets the raw metrics and outputs them to carbon which stores the time series data in whisper files (which can be swapped out for a different technology if need be).

https://www.cubicweb.org/file/15338392/raw/Screenshot_2016-09-16_11-56-44.png

If we are curious about a particular function or view that might be taking too long to generate or slow down the user experience, we can just add the @statsd_timeit decorator there. Done. It's monitored.

statsd monitoring is a fire-and-forget UDP type of monitoring, it should not have any impact on the performance of what you are monitoring.

Monitoring Apache

Simply enough we re-use the statsd approach by plugging in an apache module to time the HTTP responses sent back by apache. With nginx and varnish, this is also really easy.

https://www.cubicweb.org/file/15338407/raw/Screenshot_2016-09-16_11-56-54.png

One of the nice things about this part is that we can then get graphs of errors since we will differentiate OK 200 type codes from 500 type codes (HTTP codes).

Monitoring ElasticSearch

ElasticSearch comes with some metrics in GET /_stats endpoint, the same goes for individual nodes, individual indices and even at cluster level. Some popular tools can be installed through the ElasticSearch plugin system or with Kibana (plugin system there too).

We decided on a different approach that fitted well with our other tools (and demonstrates their flexibility!) : pull stats out of ElasticSearch with SaltStack, push them to Carbon, pull them out with Graphite and display them in Grafana (next to our other metrics).

https://www.cubicweb.org/file/15338399/raw/Screenshot_2016-09-16_11-56-34.png

On the SaltStack side, we wrote a two line execution module (elasticsearch.py)

import requests
def stats():
    return request.get('http://localhost:9200/_stats').json()

This gets shipped using the custom execution modules mechanism (_modules and saltutils.sync_modules), and is executed every minute (or less) in the salt scheduler. The resulting dictionary is fed to the carbon returner that is configured to talk to a carbon server somewhere nearby.

# salt demohost elasticsearch.stats
[snip]
  { "indextime_inmillis" : 30,
[snip]

Monitoring web metrics

To evaluate parts of the performance of a web page we can look at some metrics such as the number of assets the browser will need to download, the size of the assets (js, css, images, etc) and even things such as the number of subdomains used to deliver assets. You can take a look at such metrics in most developer tools available in the browser, but we want to graph this over time. A nice tool for this is sitespeed.io (written in javascript with phantomjs). Out of the box, it has a graphite outputter so we just have to add --graphiteHost FQDN. sitespeed.io even recommends using grafana to visualize the results and publishes some example dashboards that can be adapted to your needs.

https://www.cubicweb.org/file/15338109/raw/sitespeed-logo-2c.png

The sitespeed.io command is configured and run by salt using pillars and its scheduler.

We will have to take a look at using their jenkins plugin with our jenkins continuous integration instance.

Monitoring crashes / errors / bugs

Applications will have bugs (in particular when released often to get a client to validate some design choices early). Level 0 is having your client calling you up saying the application has crashed. The next level is watching some log somewhere to see those errors pop up. The next level is centralised logs on which you can monitor the numerous pieces of your application (rsyslog over UDP helps here, graylog might be a good solution for visualisation).

https://www.cubicweb.org/file/15338139/raw/Screenshot_2016-09-16_11-30-53.png

When it starts getting useful and usable is when your bugs get reported with some rich context. That's when using sentry gets in. It's free software developed on github (although the website does not really show that) and it is written in python, so it was a good match for our culture. And it is pretty awesome too.

We plug sentry into our WSGI pipeline (thanks to cubicweb-pyramid) by installing and configuring the sentry cube : cubicweb-sentry. This will catch rich context bugs and provide us with vital information about what the user was doing when the crash occured.

This also helps sharing bug information within a team.

The sentry cube reports on errors being raised when using the web application, but can also catch some errors when running some maintenance or import commands (ccplugins in CubicWeb). In this particular case, a lot of importing is being done and Sentry can detect and help us triage the import errors with context on which files are failing.

Monitoring usage / client side

This part is a bit neglected for the moment. Client side we can use Javascript to monitor usage. Some basic metrics can come from piwik which is usually used for audience statistics. To get more precise statistics we've been told Boomerang has an interesting approach, enabling a closer look at how fast a page was displayed client side, how much time was spend on DNS, etc.

On the client side, we're also looking at two features of the Sentry project : the raven-js client which reports Javascript errors directly from the browser to the Sentry server, and the user feedback form which captures some context when something goes wrong or a user/client wants to report that something should be changed on a given page.

Load testing - coverage

To wrap up, we also often generate traffic to catch some bugs and performance metrics automatically :

  • wget --mirror $URL
  • linkchecker $URL
  • for $search_term in cat corpus; do wget URL/$search_term ; done
  • wapiti $URL --scope page
  • nikto $URL

Then watch the graphs and the errors in Sentry... Fix them. Restart.

Graphing it in Grafana

We've spend little time on the dashboard yet since we're concentrating on collecting the metrics for now. But here is a glimpse of the "work in progress" dashboard which combines various data sources and various metrics on the same screen and the same time scale.

https://www.cubicweb.org/file/15338648/raw/Screenshot_2016-09-13_09-41-45.png

Further plans

  • internal health checks, we're taking a look at python-hospital and healthz: Stop reverse engineering applications and start monitoring from the inside (Monitorama) (the idea is to distinguish between the app is running and the app is serving it's purpose), and pyramid_health
  • graph the number of Sentry errors and the number of types of errors: the sentry API should be able to give us this information. Feed it to Salt and Carbon.
  • setup some alerting : next versions of Grafana will be doing that, or with elastalert
  • setup "release version X" events in Graphite that are displayed in Grafana, maybe with some manual command or a postcreate command when using docker-compose up ?
  • make it easier for devs to have this kind of setup. Using this suite of tools in developement might sometimes be overkill, but can be useful.

[Yaal] Publier sur pypi.python.org

Publié le 2016-08-30 22:00:00

Nous avons écrits des bibliothèques génériques qui nous simplifient la vie en réutilisant les mêmes composants génériques entre plusieurs services. Ces bibliothèques sont disponibles lors de la création de virtualenv car ils sont disponibles sur un dépôt privé (livré par devpi) que nous hébergeons. Ainsi, lorsque nous créons un virtualenv, les paquets python disponibles sont l'union des paquets disponibles sur pypi.python.org ainsi que ceux que nous avons produits. Lorsque nous avons publié MarkdownMail, une de ces bibliothèques, directement sur pypi.python.org dans l'espoir qu'elle puisse servir à d'autres, nous en avons tiré quelques enseignements :

C'est facile ! :-)

Étant donné que la structure de la bibliothèque était déjà faite préalablement, il y avait peu de travail à ce niveau-là. Les améliorations réalisées pour la publication sont listées par la suite.

Pour publier sur pypi.python.org, il suffit de créer un compte sur le service et le valider (soit un clic dans un e-mail). Ensuite, les paramètres passé au setup.py permettent de réserver un nom disponible puis d'envoyer une nouvelle version vers pypi.python.org (cf. https://docs.python.org/3.4/distutils/packageindex.html).

Classifiers

Les classifiers du setup.py aident les utilisateurs à avoir une idée de l'application ou de la bibliothèque. Ils servent aussi pour trouver plus facilement ce que l'on cherche parmi les paquets disponibles.

Nous nous en servions déjà en interne pour définir certains éléments, en particulier pour expliciter la compatibilité de nos bibliothèques avec python 2 et/ou python 3. Il a suffit d'en rajouter certains pour être plus complet.

README

Ajouter un fichier README à la racine est un moyen habituel de documenter la bibliothèque. En faisant lire son contenu comme description longue dans le fichier setup.py, il sera affiché sur la page du paquet et sera donc directement lisible par les utilisateurs. Si le texte est au format reStructuredText (reST), alors il est affiché en html automatiquement. Dans le cas contraire, il sera simplement affiché comme du texte brut, dans une police à chasse variable. Dans ce cas, le rendu n'est pas très lisible, en particulier pour les exemples de code source.

reST ressemble à du Markdown mais n'en est pas. Pour ceux qui publient le code sur GitHub, GitHub fait un rendu HTML des README au format reST, et pas uniquement au format Markdown.

Tox

En rendant la bibliothèque publique, il est bon de valider les tests avec plusieurs versions de python. En interne, les versions sur lesquelles le code doit fonctionner sont connues (2.7 ou 3.4 actuellement chez nous). Tox est l'outil classique pour le faire et son intégration avec setup.py est documentée.

Devpi + pypi.python.org

Une fois que la bibliothèque est déjà présente en interne via devpi, il n'est plus possible d'en récupérer une plus récente sur pypi.python.org. Cela est dû à des raisons de sécurité : dans le cas contraire, un attaquant connaissant le nom d'un paquet utilisé en interne pourrait envoyer un paquet plus récent sur pypi.python.org. Ensuite, lors de la création d'un nouveau virtualenv, ce paquet serait installé au lieu du paquet interne, provoquant par la suite l'exécution du code de l'attaquant et non le code développé par le créateur de la bibliothèque.

Pour rendre ce cas possible, il suffit de modifier la configuration de devpi. Nous avons ajouté MarkdownMail à une liste blanche pour limiter l'effet de la modification.

Pyroma

Pyroma permet de connaitre les éléments manquants à un paquet. Il permet de tester les différents éléments de la bibliothèque pour améliorer la qualité du paquet. Par exemple, il signale l'absence des champs « keywords » ou « licence ». Pyroma ne remplace pas des outils vérifiant PEP8.

Environnement de dév. pour pypi.python.org

pypi.python.org permet d'envoyer la bibliothèque vers un dépôt de tests pour valider une bibliothèque avant de la rendre accessible au reste du monde. Pour cela, il suffit de préciser le dépôt dans lequel insérer une nouvelle version d'un paquet (grâce au paramètre -r).

De nouvelles évolutions sont envisagées pour améliorer l'usage de MarkdownMail pour les développeurs externes à Yaal, comme le fait de simplifier la possibilité de signaler des bogues ou faire des patchs. Cependant ces évolutions sont indépendantes de pypi. Le fait de publier cette bibliothèque nous a permis de l'améliorer et, plus généralement, de progresser sur les paquets python.

[afpyro] AFPYro à Pau - Mercredi 10 Août

Publié le 2016-08-10 00:00:00

Nous vous invitons à {v,n}ous retrouver autour d’un verre au Garage le 10 Août à partir de 19h30 pour ce premier AFPYro palois de 2016.

Le Garage Bar
47 Rue Emile Garet
64000 Pau
France

[ascendances] Redimensionner des images avec python-resize-image

Publié le 2016-08-03 14:20:04
python-resize-image est une bibliothèque python disponible sur pypi.python.org. C’est une surcouche à PIL qui simplifie son usage pour des redimensionnements courants d’image. Bien pratique, elle ne remplacera pas PIL pour toutes les autres possibilités comme les empilements d’image par exemple. La bibliothèque est utilisable avec python2 et python3 mais le fichier wheel n’a été fait […]

[carlchenet] My Free Activities in May 2016

Publié le 2016-06-06 22:00:49
Follow me also on Diaspora* or Twitter  Trying to catch up with my blog posts about My Free Activities. This blog post will tell you about my free activities from January to May 2016. 1. Personal projects db2twitter 0.6 released (Github stars appreciated ) – sending tweets with image feed2tweet 0.4 released (Github stars appreciated)… Continuer de lire My Free Activities in May 2016

[Yaal] Sud Web 2016 : Retour sur l’édition Bordelaise

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

Journée 1 - Les conférences

C’est la première édition de Sud Web à laquelle nous participons, nous étions ainsi très curieux du format que ce rassemblement allait prendre.

La première journée proposait des conférences sur différentes thématiques. Bien accueillis par des viennoiseries et du café pour bien commencer la journée, nous avons très vite enchaîné avec le programme du jour. Les différents speakers se sont relayés tout du long via différents formats de conférences allant de 5 à 30 minutes. Les plus longues étant entrecoupées par des plus courtes pour dynamiser la programmation.

Le fil rouge qui articulait les talks entre eux, était une allégorie du fait de grandir. La maîtresse de cérémonie - une ex-ingénieur, à présent comédienne (Pauline Calmé) - jouait la carte de l’humour, en illustrant au travers de courtes scénettes les différents âges de la vie, de l’enfance à l’âge adulte. Cela permettait d’introduire les conférences sous un angle différent, évitait le moment de blanc entre les intervenants, permettait de détendre le public et symbolisait le cheminement du domaine du web, de ses balbutiements jusqu’à son âge actuel.

Côté speakers, de nombreux points positifs sont à mentionner : une envie de partager des expériences, une passion pour leur travail et une capacité de vulgarisation de leurs sujets pour qu’ils soient accessibles à tous. A Sud Web, on essaie de parler à tout le monde, que l’on soit ingénieur ou designer. Les problématiques et les expériences remontées sont suffisamment globales pour que personne ne soit mis de côté.

photo par Nazcange des participants

Photo par Nazcange

L’aspect très ancré dans l’actualité des thématiques abordées était fort appréciable : le talk sur le Code & Travail par Rachel Saada, avocate au barreau de Paris, les questionnements et inquiétudes concernant le marché du travail soulevés par Roxane Debruyker ou encore l’intervention de Matthew Caruana Galizia - journaliste et développeur web à l’ICIJ - sur le traitement et l’exploitation des données dans l’affaire des Panama Papers; sont le reflet de ce qu’il se passe dans la société et comment cela impacte le domaine du web dans lequel nous travaillons.

La présence d’une quasi-parité au niveau des intervenants est également un point suffisamment rare au sein des conférences pour être souligné. Sur 17 intervenants, notons la présence de 7 femmes, issues de toutes professions - de l’ingénierie au design - et d’une maîtresse de cérémonie.

Niveau organisation, les conférences étant ponctuées par des moments de pause pendant lesquels il était possible d’échanger tous ensemble et avec les speakers. L’avantage de suivre toutes les conférences est de pouvoir débattre pendant ces instants sociaux. C’est l’occasion de rencontrer des visages que l’on ne connait que via les réseaux, de se confronter à des profils nouveaux et d’échanger ensemble. La soirée de vendredi regroupait tous les participants au Potato Head, ce qui permettait de discuter dans un cadre plus intimiste et de prolonger les échanges débutés dans la journée. L’avantage des places limitées amenant un format plus convivial aux visiteurs et favorisant l’interaction par petits groupes.

photo par Marie Guillaumet de la conférence de Stefanie Posavec

Photo par Marie Guillaumet

Notre coup de coeur conférence

Nous avons beaucoup apprécié le retour de Stefanie Posavec sur son projet mené sur 52 semaines intitulé «Dear Data». Avec une autre designer d’informations, elles s’étaient données pour challenge de choisir d’enregistrer différents type de données de la vie de tous les jours et de se les envoyer mutuellement par la poste, avec chaque semaine une thématique différente : le nombre de fois où elles avaient dit merci, le nombre de fois où elles avaient rit, … et de les traduire sous forme de data visualisation sur des cartes postales à l’aide de crayons de couleurs, de feutres et d’autres outils de dessin traditionnel.

La démarche regorge d’idées intéressantes et porte un regard nouveau sur ces petits gestes du quotidien que l’on fait sans s’en rendre vraiment compte et que la technologie ne peut pas (encore !) enregistrer.

Journée 2 - Le forum ouvert

La deuxième journée reposait sur un système d’auto-organisation, via un forum ouvert. Les participants se réunissaient dans un lieu où différentes salles étaient mises à leur disposition pour organiser des ateliers, des débats, des séances de réflexion collectives sur des thématiques que tout le monde pouvait proposer et auxquelles chacun pouvait se rendre et en partir à loisir (pratique quand on a deux activités qui nous plaisent autant l’une que l’autre dans le même créneau horaire !). A nouveau, l’avantage du nombre limité de participants rendait les activités accessibles à tous, pour que chacun y trouve son compte et dans de bonnes conditions. De ce fait, cela permettait à tout le monde de devenir un acteur de Sud Web et de favoriser de nouveau les échanges et la collaboration.

photo par Marie Guillaumet des ateliers proposés

Photo par Marie Guillaumet

Parmi les ateliers proposés spontanément par les participants, on dénombrait de nombreux axes comme «Enseigner le web, ensemble ?» qui permettait de réfléchir sur les différentes méthodes d’enseignement existantes et sur les bonnes manières de transmettre ses connaissances, un atelier sur la revue de code et quelles étaient les bonnes pratiques, un atelier pour décrypter sa fiche de paie ou en savoir plus sur la mise en place du télétravail, une table ouverte sur le Burn out, comment le détecter et l’éviter, etc… (et même un très chouette atelier lettering et crayolas proposé par Laurence Vagner pour changer des pixels !)

Verdict : à refaire !

Cette première édition de Sud Web s’est révélée être une expérience agréable et très ancrée dans le monde du web d'aujourd'hui. Le format actuel est bien pensé et permet de proposer aux participants le passage d’une expérience de spectateur à celui d’acteur de la conférence.

Parmi les valeurs et les idées qui dominaient cette édition, le fait de se sentir bien dans sa vie et dans son travail, le partage, la participation, l’investissement des individus dans des initiatives collectives ou personnelles et l’envie d’apporter à la société et à notre domaine via des alternatives au système classique témoignent de l’évolution des métiers du web en France.

L’équipe (la «Thym» Sud Web) qui organise l’événement a effectué un travail remarquable, le mot à retenir de cette expérience est «Bienveillance». Une bienveillance que l’on retrouve aussi bien au niveau des organisateurs que des participants, qu’ils soient speakers ou visiteurs.

Nous sommes plutôt satisfaits de cette première expérience Sud Web et sommes convaincus de revenir l’année prochaine ! Et pourquoi pas, de proposer une thématique pour un forum ouvert autour du travail en équipe auto-organisée ou d’un retour d’expérience sur Yaal afin de rencontrer d’autres profils à la recherche d’alternatives plus humaines au monde du travail classique.

[AFPy-Nantes] Annonce meetup du mois de mai 2016 : Celery & Sentry

Publié le 2016-05-25 22:00:00

La prochaine rencontre Python Nantes sera au format Présentations et se déroulera le mercredi 18 mai de 19h à 21h, à la Cantine de Nantes.

celery
  • Arthur Lutz (@arthurlutz) de Logilab présentera un retour sur Sentry (collecteur d'erreurs python écrit en python, mais aussi javascript et autres)
sentry

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.

Le meetup est gratuit mais il faut s'inscrire sur http://www.meetup.com/Nantes-Python-Meetup/events/230661649/.

À bientôt !

[carlchenet] Tweet your database with db2twitter

Publié le 2016-05-24 22:00:51
Follow me also on Diaspora* or Twitter  You have a database (MySQL, PostgreSQL, see supported database types), a tweet pattern and wants to automatically tweet on a regular basis? No need for RSS, fancy tricks, 3rd party website to translate RSS to Twitter or whatever. Just use db2twitter. A quick example of a tweet generated… Continuer de lire Tweet your database with db2twitter

[sciunto] Contributions #2

Publié le 2016-05-21 22:00:00

Voici une brève d'un certain nombre de mes contributions de ces trois derniers mois. Le but est de montrer qu'il y a plein de choses à faire et que chaque petit pas contribue à faire avancer le Libre.

Associations

Je me suis lancé à donner un coup de main à framasoft et la quadrature.

  • Un relecture d'une page web sur les NAS pour le site controle-tes-donnees et j'ai par ailleurs démarré deux autres tickets, un premier pour parler de CHATONS (je propose un texte) et un second pour réfléchir au contenu des pages auto-hébergement. N'hésitez-pas à contribuer.
  • Chez framasoft, j'ai aidé à la révision de la charte et aussi et émis une idée. Cette structure est très intéressante et je vais continuer à m'investir pour favoriser l'émergence.
  • De plus, j'ai démarré une liste de potentiels chatons ce qui permettra de démarcher des structures existantes et aussi d'avoir une idée plus précise de ce à quoi ça peut ressembler.

Archlinux

  • J'ai créé un paquet archlinux pour trimage. Ce serait intéressant de retravailler un peu sur le code et passer à python 3. Les derniers commits datent de trois ans.

Scikit-image

Scikit-image est une bibliothèque Python pour le traitement d'images (scientifique), que j'utilise assez souvent. Il y avait longtemps que je n'avais pas contribué, alors je m'y remets.

  • Suite à une utilisation avec des choses qui ne me plaisaient pas, je me suis lancé dans la relecture du code des fonctions de transformée de Hough pour les lignes. Ca m'a pris pas mal de temps pour me rendre compte qu'une précision manquait dans la doc et qu'il y avait une erreur dans la signature d'une fonction cython. Je tente aussi de mettre en place une détection de pic subpixellaire, mais ce n'est pas gagné.
  • J'ai apporté une correction de bug à cause d'un morceau de code qui n'avait pas été testé dans toutes les combinaisons d'option possible. C'est une fonction portant sur la détection de pics locaux.

Python

  • Suite à une analyse de performance de code de feedparser, j'ai créé un petit patch dont une partie a été fusionné. J'espérais pouvoir gagner plus en me lançant dans cette analyse, mais l'étude fût instructive.
  • Suite à mes activités d'empaqueteur pour archlinux, j'ai ouvert un ticket chez pandas lié à numexpr. Je suis tombé sur un dev assez peu agréable et le ton est un peu monté. Face à ça, j'ai arrêté de commenter et il a corrigé le bug tout seul. Une remarque : ce n'est pas parce que le bug tracker enregistre plusieurs milliers de tickets qu'il faut expédier les nouveaux sans analyser finement ce qui se passe et prendre le temps de poser les questions. Sur le long terme, c'est contre-productif.

Divers

  • J'utilise Jirafeau comme hébergeur de fichier et j'ai créé un petit patch pour que le script bash renvoie tous les liens.
  • Pour bibtexbrowser, j'ai proposé que l'url de jquery soit une variable. Ainsi, on permet au websmaster de respecter la vie privée des utilisateurs en utilisant sa propre installation.
  • Un rapport de bug pour simple-scan dont la fenêtre d'enregistrement n'est pas très intuitive pour les personnes ne comprennant pas le sens d'une extension de fichier. Or, ce logiciel s'adresse à ce type de public.

[sciunto] Construire notre communication : blogs, planets, journaux...

Publié le 2016-05-18 22:00:00

A l'heure actuelle, j'écris sur ce blog, relayé par ces deux planets et parfois par le journal du hacker (jdh) pour lequel j'ai un peu contribué. Deux article récents, un premier par un contributeur du jdh et un second par un contributeur du planet-libre. pose des analyses quant à l'avenir des planets, ces sites relayant par le biais de flux rss, des articles de blog.

L'un des constats serait une baisse du nombres des blogs et des articles publiés, et donc de l'intérêt des planets. J'ai bien vu ces deux articles, et j'y avais donc réfléchi sans prendre la peine de l'écrire. Je le fais donc maintenant suite à une invitation indirecte.

Les blogs ont-ils un avenir ?

Sur l'intérêt des blogs, ça me semble essentiel. C'est ce qui fait partie de la culture Hacker, avec les wikis pour documenter ce que l'on fait. En deux mots, le terme Hacker recouvre ici toute personne ayant une activité de détournement d'objet afin de résoudre des problèmes pour lesquels ils ne sont pas destinés ainsi que la construction de l'informatique avec l'esprit du logiciel libre. Sans prétention aucune, c'est pour cela que j'ai les deux formes (blog.sciunto.org et share.sciunto.org). Le blog est en français (pour l'instant), le wiki en anglais. Ces deux formes sont complémentaires, l'un formant un carnet de bord, l'autre une documentation plus pérenne.

 L'intérêt des planets

L'intérêt d'un planet est de mettre en valeur les activités des acteurs d'un domaine. Le fait qu'il y ait plusieurs planets n'est donc que la conséquence de l'existence de divers groupes qui se chevauchent. Il reste selon moi un formidable tremplin pour communiquer. La duplication des articles pour certains lecteurs n'est selon moi pas un problème majeur. Je peux très bien suivre le planet-python mais pas le planet-debian et pour autant être intéressé par un article python appliqué à debian.

 Le relais ou la communication par les réseaux sociaux

Je ne suis pas adepte des réseaux sociaux. Les modèles de type facebook enferment les données et espionnent les activités. Je n'ai aucune idée de ce qui peut se dire sur ces réseaux. Le modèle me semble contraire à mon éthique, je n'y vais donc pas. Les modèles de type twitter sont ouverts, mais ont un ratio signal/bruit très souvent faible. De plus, mon observation me pousse à conclure que cette outil donne une illusion de visibilité : un buzz chez les convaincus, mais invisible au delà..

Le journal du hacker

Le modèle du jdh a des intérêts mais aussi des défauts selon moi. Déjà, je tiens à saluer l'initiative parce que c'est une belle façon de partager de l'information avec un outil intéressant. Par contre, je déplore la ligne éditoriale.

Trop d'articles bas de gamme sont relayés, notamment avec des sites professionnels qui ont pignon sur le web, dont les articles sont en carton : du journalisme classique se contentant de relayer de l'information avec de l'enrobage, des titres accrocheurs et une réflexion au degré zéro de la pensée.

L'autre problème est qu'il n'y a que quelques contributeurs qui publient beaucoup. La diversité n'est pas au rendez-vous et en postant des liens à tour de bras, on n'a pas une sélection d'articles qui ont ce quelque chose qui les rendent uniques. En effet, à chaque lien posté, il n'y a que rarement une justification de l'intérêt du lien. Les discussions sont par ailleurs quasi inexistantes contrairement à hacker news dont le jdh est un clone francophone libre. Donc, le jdh devient un planet bis avec, en plus, des articles moins intéressants à mes yeux. J'en suis venu à filtrer les noms de domaines pour faire une pré-sélection drastique.

Enfin, dernier point, dans jdh (journal du hacker), il y a hacker, et je vois trop peu de choses sur la bidouille d'objets physiques (contrairement à Hackaday), ce qui est bien dommage.

Vers un idéal ?

Hackaday représente selon moi un modèle de ligne éditoriale et s'il y avait quelque chose à reprendre, ce serait bien cette forme là, mais avec une meilleure répartition entre "software" et "hardware". Ils sont d'avantage dans un modèle où ce sont des lecteurs ou des rédacteurs qui viennent proposer leurs articles en plus de la veille de leurs contributeurs. Si une page est intéressante, un petit laïus avec éventuellement une photo ou vidéo est rédigé, avec parfois des liens vers des articles antérieurs publiés sur hackaday. A ma connaissance, ceci n'existe pas en français et il est évident que ça demanderait de l'énergie à construire une solution similaire.

[sciunto] Grammalecte : sortie du greffon pour firefox

Publié le 2016-05-15 22:00:00

Au printemps dernier avait été lancé une campagne de financement pour grammalecte, un correcteur grammatical et typographique dont la teneur est expliquée notamment sur linuxfr. Il y a quelques mois, je rapportais des nouvelles de l'avancement du logiciel dans cet article afin d'utiliser le correcteur grammatical en ligne de commande.

Désormais, le greffon pour firefox est disponible et voici l'annonce. Plus aucune excuse pour faire des fautes sur le web !

[carlchenet] Feed2tweet, your RSS feed to Twitter Python self-hosted app

Publié le 2016-05-03 16:15:52
Feed2tweet is a self-hosted Python app to send you RSS feed to Twitter. Feed2tweet on Github (stars appreciated ) The official documentation of Feed2tweet on Readthedocs. Feed2tweet on PyPi Feed2tweet is in production for Le Journal du hacker, a French Hacker News-style FOSS website and LinuxJobs.fr, the job board of the French-speaking FOSS community. Feed2tweet… Continuer de lire Feed2tweet, your RSS feed to Twitter Python self-hosted app

[sciunto] Faille de sécurité pour gitlab. Correction le 2 mai

Publié le 2016-04-29 22:00:00

Gitlab a annoncé l'existence d'une faille de sécurité CVE-2016-4340. On ne connait pas encore les détails de cette dernière. D'après hacker news, de nombreuses versions sont affectées :

  • 8.7.0
  • 8.6.0 à 8.6.7
  • 8.5.0 à 8.5.11
  • 8.4.0 à 8.4.9
  • 8.3.0 à 8.3.8
  • 8.2.0 à 8.2.4

Gitlab annonce un correctif le 2 mai, publié à 23:59 GMT.

L'annonce à l'avance de la faille fait craindre une monté en privilège assez facile de la part d'un attaquant. Sur les commentaires de hacker news, il est indiqué qu'une analyse post-mortem sera effectuée.

En attendant, j'ai choisi de stopper mon instance gitlab avant la publication du correctif, afin d'avoir le temps de l'appliquer sereinement.

[AFPy Salt-fr] Annonce : Meetup Mai 2016 : Salt, Docker, Sentry

Publié le 2016-04-26 22:00:00

Tests d'intégration avec Salt & Docker, collecte d'erreurs Salt avec Sentry

Le meetup de mai de Salt se déroulera le jeudi 12 mai à partir de 19h, autour des sujets suivants :

  • Séven Le Mesle (@slemesle) de

    WeScale présentera un retour d'expérience sur la façon dont ils utilisent Salt et Docker pour réaliser des tests d'intégration permettant de valider la configuration de machine provisionnées avec Salt

salt & docker
  • Arthur Lutz (@arthurlutz) de Logilab présentera un retour d’expérience sur l'utilisation de Sentry pour collecter les logs, retours et erreurs sur une infrastructure pilotée par Salt.
salt & sentry

WeScale sponsorise le meetup en nous accueillant et en proposant un buffet après les présentations. L'adresse est le 156 bd Haussmann, Paris (Metro Miromesnil).

wescale

Le meetup est gratuit mais il faut s'inscrire sur meetup.com

[afpyro] AFPYro à Nantes - mardi 20 avril

Publié le 2016-04-20 00:00:00

Nous vous invitons à {v,n}ous retrouver autour d’un verre au café Flesselles le 20 avril pour ce premier AFPYro nantais de 2016.

Vous pouvez nous informer de votre présence :

[carlchenet] Richard Stallman ce samedi à Choisy-le-roi

Publié le 2016-04-11 06:53:47
Pour information j’ai découvert ce week-end que Richard Stallman sera présent à la médiathèque de Choisy-le-roi ce samedi 16 avril 2016 à 17h. Pour information des Parisiens indécrottables, c’est en très proche banlieue parisienne :p Comptez par exemple entre 20 et 30 mn depuis le centre de Paris en passant par le RER C pour… Continuer de lire Richard Stallman ce samedi à Choisy-le-roi

[carlchenet] Nouveau forum pour l’emploi dans la communauté du Logiciel Libre et opensource

Publié le 2016-04-03 22:00:31
Suivez-moi aussi sur Diaspora* ou Twitter  Un rapide message pour annoncer le lancement d’un forum dédié à l’emploi dans la communauté du Logiciel Libre et opensource : Le forum de LinuxJobs.fr : https://forum.linuxjobs.fr Devant le succès de LinuxJobs.fr , le site d’emploi de la communauté du Logiciel Libre et opensource, et la communauté d’utilisateurs qui… Continuer de lire Nouveau forum pour l’emploi dans la communauté du Logiciel Libre et opensource

[carlchenet] Le danger Github (revu et augmenté)

Publié le 2016-03-31 21:00:43
Suivez-moi aussi sur Diaspora* ou Twitter  Alors que le projet CPython (implémentation historique du projet Python) a annoncé son passage chez Github (avec quelques restrictions, nous reviendrons là-dessus), il est plus que jamais important de s’interroger sur les risques encourus d’utiliser un logiciel propriétaire dans notre chaîne de création du Logiciel Libre. Des voix critiques… Continuer de lire Le danger Github (revu et augmenté)

[carlchenet] Du danger d’un acteur non-communautaire dans votre chaîne de production du Logiciel Libre

Publié le 2016-03-28 21:00:23
Suivez-moi aussi sur Diaspora* ou Twitter  La récente affaire désormais connue sous le nom de npmgate (voir plus bas si cet événement ne vous dit rien) est encore une illustration à mon sens du danger intrinsèque d’utiliser le produit possédé et/ou contrôlé par un acteur non-communautaire dans sa chaîne de production du Logiciel Libre. J’ai… Continuer de lire Du danger d’un acteur non-communautaire dans votre chaîne de production du Logiciel Libre

[sciunto] Ressources sur le libre

Publié le 2016-03-24 23:00:00

Voici une liste de ressources pour se tenir informer, se sensibiliser ou encore agir sur les thématiques du logiciel libre et de la neutralité de l'internet.

Actualités

 Conférences

 Sites de sensibilisation

Sites d'activité citoyenne

Miscellanées

Autres ?

Si vous avez des suggestions, ne pas hésiter à me les envoyer par courriel.

[Yaal] Élargir la cible des utilisateurs au fur et à mesure de leur satisfaction

Publié le 2016-03-17 23:00:00

Le premier groupe d'utilisateurs

La première étape d'une startup est de trouver un positionnement lui permettant d'obtenir des utilisateurs satisfaits. Le cas échéant, il lui faudra pivoter à la recherche d'un meilleur positionnement. Une fois un positionnement satisfaisant obtenu, le nouvel objectif est d'obtenir de la croissance (utilisateur et/ou chiffre d'affaire).

croissance

Dans le cas d'un objectif de croissance utilisateur, une des stratégie est de ne viser en premier lieu qu'un petit groupe et d'en faire des utilisateurs convaincus. Cela permet d'en faire des prescripteurs du service, ce qui participe aussi à la croissance.

De plus, une fois que l'acquisition du marché visé est assez grande, l'entreprise bénéficie d'un effet de réseau : à l'image du réseau téléphonique, plus le service est utilisé et plus les utilisateurs ont intérêt à l'utiliser. Cela permet d'acquérir plus facilement de nouveaux utilisateurs.

Les groupes d'utilisateurs suivants

Une fois le premier groupe convaincu, le but sera d'en satisfaire de nouveaux sans décevoir les premiers. C'est ce qu'a fait Facebook, en limitant l'usage aux étudiants d'Harvard, puis à tous les étudiants, puis au reste du monde.

croissance

Les versions successives du service permettent donc d'élargir la cible au fur et à mesure de l'acquisition d'utilisateurs, parallèlement à la communication vers les nouveaux groupes visés. Développer et publier de nouvelles versions par itération est adapté à cette stratégie. L'acquisition des utilisateurs se ralentissant une fois le point d'inflexion passé, la cible suivante ne doit être visée qu'ensuite.

Si cette stratégie est séduisante, il ne faut pas en négliger les limites :

  • la taille des marchés visés et la puissance de l'effet réseau est connue approximativement. Des études de marchés permettent de limiter cette incertitude.
  • le passage d'une cible à l'autre doit se faire sans perdre les précédents. Cela oblige à une suite logique d'acquisition des cibles visées.
  • elle s'adapte à un service visant les utilisateurs finaux, pas aux entreprises.

Un des avantages est de permettre le démarrage sur une niche connue des concepteurs, limitant la taille du produit minimum viable et donc les coûts de démarrage. Cela permet de valider rapidemment le service et les choix de départ. L'élargissement sera fait en sortant de la niche, ce qui est un chemin assez facile à réaliser. Le service proposé sera alors plus générique, visant un public de plus en plus large.

Agilité

Nous apprécions cette vue stratégique en accord avec les moyens tactiques qu'offrent les méthodes agiles, lucides sur la nécessité d'apprendre, de s'adapter et d'innover pour une entreprise en croissance.

[sciunto] NAS : choix des composants

Publié le 2016-03-10 23:00:00

Dans ce billet, j'établis mon choix pour le montage d'un NAS.

Mon état des lieux est le suivant. J'ai plus de 8To de données personnelles et professionnelles qui sont actuellement sur des disques durs usb. Il devient compliqué de brancher et débrancher, de manipuler sans laisser tomber, de savoir quoi est sur qui.

La sauvegarde est un enfer : sauvegarde de machines sur des disques, de machines sur des machines, de disques sur des disques, etc. J'ai toutes les chances de rater un étape. L'idée est donc de rationnaliser tout ça :

  • Une machine qui héberge données et sauvegarde des desktops/serveurs.
  • Une autre machine qui sauvegarde les données critiques du NAS.

Avantages/inconvénients d'un NAS

Avantages

  • Espace de stockage continu plutôt que N disques distincts
  • Espace disponible sur le réseau (communication avec plusieurs machines, montage NFS...)
  • Facilite grandement la sauvegarde régulière
  • Résilient à des pannes disques (ça dépend du RAID choisi, mais je m'intéresse à un système résilient)

Inconvénients

  • Si un nombre critique de disques flanche ou un autre problème apparait (erreur de manipulation, matériel défaillant causant une perte majeure des disques), on perd tout.
  • Machine supplémentaire donc coût supplémentaire comparé à un boitier de disque externe.
  • Les disques de parité sont de la mémoire morte, c'est-à-dire de l'espace non visible par l'utilisateur.
  • Un système RAID n'est pas une sauvegarde, il faudra donc sauvegarder.

Choix technologiques

  • De la redondance de données pour être résilient aux pannes disques.
  • Système de fichiers ZFS qui est éprouvé pour ce genre d'usage (en attendant que btrfs soit mature).

Par conséquent, on s'oriente vers un RAIDz1, 2 ou 3, c'est-à-dire 1, 2 ou 3 disques de redondance. A l'heure actuelle, il semble que RAIDZ1 soit déconseillé. L'argument est le suivant. Les disques sont de plus en plus gros. Par conséquent, si un disque est en panne, il est nécessaire de le remplacer pour reconstruire le pool. La charge appliquées sur les disques est d'autant plus grande que chaque disque est volumineux. Il y a donc un risque (non négligeable ?) qu'un second disque casse à ce moment là. RAIDZ3 demande beaucoup d'investissement. J'opte donc pour RAIDZ2. Le nombre minimal de disques est de 4 et il est conseillé d'avoir un nombre pair.

Les NAS commerciaux

On va voir que notre machine sans disque présentée ci-dessous peut recevoir jusqu'à 12 disques. Bien plus qu'il nous en faut. Les NAS commerciaux de 2 ou 4 disques sont courants. Si on se base sur des marques bien connues comme synology, il faut compter

  • 2 baies 300-350€
  • 4 baies 450€
  • 5 baies 600-700€
  • 6 baies 700-800€
  • 12 baies à 1300€.

C'est un prix typique plutôt minimaliste, on peut sans problème trouver bien plus cher. Je n'ai pas vu de synology à 6 baies.

D'un point de vue rentabilité, un 4 baies est juste pour un RAID6 (=RAIDZ2 pour ZFS), car seule la moitié de l'espace acheté sera disponible. Le 5 baies étant le plus proche, je vais comparer avec le DS1515 :

  • quad core 1.4 GHz
  • 2 Go RAM
  • disques EXT4 hot swappable
  • Extension possible à 15 disques, mais avec un module coutant 450€ / 5 disques supplémentaires
  • Ajout d'un disque SSD possible (Les tests de performance présentés sur le site utilisent un SSD)

L'avantage d'un tel NAS est le coté clef en main du produit (d'après ce que je lis). Par contre, les inconvénients que je vois :

  • peu d'évolutivité en nombre de disques ou chère
  • logiciel propriétaire
  • pour un RAID6, je n'ai que 5-2 = 3 fois la taille d'un disque disponible. La sacrifice est important.
  • le 8 baies est bien plus cher

Pour un prix légèrement inférieur, ma proposition ci-dessous me donne

  • quad core 2.4 GHz
  • 16Go RAM ECC
  • disques en ZFS (ou autre chose)
  • Avec le boitier, on peut y mettre jusqu'à 8 disques facilement, 10 sans trop de difficulté.

Pour l'évolutivité :

  • Possibilité d'ajouter deux disques SSD pour améliorer les performances si le besoin sans fait sentir (pour NFS ?).
  • Possibilité de monter jusqu'à 64 Go de RAM (je reviendrai là dessus).
  • Possibilité d'ajouter de la ventilation.
  • Possibilité d'en faire autre chose qu'un NAS si les besoins devaient évoluer brutalement.

Le choix

Pour le matériel, et notamment la partie critique (carte mère, mémoire, etc), je conseille LDLC car ils ont un excellent support téléphonique (déjà testé), une bonne politique de retour, un site bien fait et une livraison gratuite dans des points relais. Les choix ne sont pas neufs en soi. Je me suis largement inspiré des conseils donnés sur le forum de freenas et quelques blogs.

Le système d'exploitation

BSD gère nativement ZFS, mais ça reste possible avec debian. Néanmoins, j'ai une confiance plus grande sur un support natif, je m'oriente donc vers FreeNAS pour la distribution. La documentation de FreeNAS est exhaustive, le forum est très actif et possède beaucoup de contenu.

UPS

Le nombre de disques durs peut être important. Je veux que ça tienne un minimum et avoir le temps d'éteindre proprement. De plus, les capacités des batteries peuvent diminuer au cours du temps, il faut prendre ce paramètre en compte.

Carte mère

Les critères que j'ai retenu :

  • le nombre de port SATA
  • la capacité en mémoire vive (FreeNAS en consomme beaucoup et de manière générale, c'est plutôt bien de ne pas en manquer)
  • le réveil par réseau (Wake On LAN)
  • la consommation énergétique (inférieure à 50W)

ASRock fabrique de très belles cartes mères pour les serveurs. Mon choix s'est porté sur une version 4 coeurs. En 8 coeurs, la différence de prix est selon moi trop importante pour une utilité relative sur un NAS. Le petit plus que j'apprécie : le CPU est livré avec la carte mère, pas besoin d'aller jouer avec la pâte thermique.

Version Quad core

Caractéristiques :

  • mini itx
  • Intel Avoton C2550 Quad Core 2.4GHZ featuring 14W TDP
  • 16 Go par slot, 64 max, 4 slots
  • 12 SATA (4 SATA2, 8 SATA3)
  • Support de l'IPMI
  • 3 ports USB (dont un pour l'UPS, et un pour l'OS)

Version Octa core

Les autres caractéristiques sont identiques à ci-dessus.

RAM ECC

Il est important d'utiliser des mémoires ECC. C'est recommander par freenas pour éviter les corruptions de données.

8Go est le minimum pour FreeNAS, 16Go devrait être à peu près confortable avec la possibilité de passer à 32Go. Les mémoires de 16Go sont un peu trop couteuses ici. Notre système se limitera donc à 32Go pour des raisons de coûts.

Chassis

Critères :

  • de l'espace, pour faire circuler l'air et pour faciliter l'installation.
  • un grand nombre d'emplacements pour disques 3.5"
  • de la ventillation et des filtres pour la poussière
  • des cables bien rangés
  • compatible carte mini itx

Mon choix :

Caractéristiques :

  • alim ATX/EPS
  • 2 SSD (à placer sur le coté)
  • 8 disques 3.5" ou 2.5"
  • 2 espaces pour lecteurs optiques dans lesquels il serait possible de mettre deux racks pour disques durs 3.5" ou 2.5"
  • 2 ventilateurs 140mm fournis
  • un grand nombre de réceptacles pour des ventilateurs supplémentaires

 Alim

Il faut donc choisir une alimentation ATX/EPS. Toujours prendre de la qualité pour éviter de sentir un jour le plastique brûlé.

  • FSP AURUM S400 400W 80PLUS Gold 60€ (LDLC)
  • Enermax Revolution XT ERX430AWT 80PLUS Gold 75€ (LDLC)

USB

  • SanDisk Cruzer Fit 16 Go 6€

Avantages :

  • petit prix
  • deux fois l'espace nécessaire à freenas
  • 5 mm de longueur. Elle s'oublira à l'arrière de la machine.

Disques

Je privilégie :

  • des disques de récupération (en bon état tout de même)
  • des disques à faible vitesse (5400 tours/min) car ils chauffent moins
  • des disques WD red, j'en ai une très bonne expérience

A noter que la taille totale disponible dépend de la taille du plus petit disque. Il faut aussi réfléchir aux besoins futurs avec les remarques suivantes :

  • On ne pourra pas ajouter de disques. Il n'est pas raisonnable de mettre deux vdev, et il est impossible d'étendre un vdev.
  • Quel coût existera-t-il si on veut augmenter la taille de chaque disque ? Quel gain ? Faut-il le faire maintenant ou plus tard (évolution des prix, existant).

Ces choix sont à faire au cas par cas. A noter aussi qu'il est déconseillé d'acheter tous les disques de même modèle, en même temps, chez le même fournisseur. La probabilité qu'ils tombent en panne simultanément est plus grande.

Connectique

  • La carte mère est venue avec 6 cables SATA. A compléter si on veut passer à 8.
  • L'alimentation possède un nombre limité de connecteur d'alim SATA (5). Il faut donc soit mettre des dédoubleurs sur des fiches molex (que l'on utilise pas), soit des extensions de fiche SATA.

SSD

Il n'est pas encore clair qu'un disque SSD apporte des améliorations pour mon utilisation (cf reddit ou Introduction to vdev, zpool, ZIL, L2ARC). Le point sensible est ici la partie NFS qui peut avoir besoin d'un cache pour être plus rapide. De même que pour les NAS assemblés, c'est optionnel et souvent laissé au regard de l'utilisateur. La documentation de freenas indique qu'il faut privilégier la RAM en premier.

Liens intéressants

[sciunto] Webmasters, installez vos libs pour respecter vos utilisateurs

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

C'est un fait désormais bien établi, les services pour webmasters permettent de suivre le déplacement des utilisateurs sur le web. A titre d'exemple, on trouve google analytics ou les bibliothèques (javascripts, fonts) hébergées notamment par google. A titre d'exemple, une liste est disponible sur developers.google.com.

Installer ces libraries sur son serveur est en réalité très simple. Prenons l'exemple de jquery et mathjax sur apache. Pour ceux qui ne sont pas familier, mathjax permet d'afficher des équations sur son site web ou dans Jupyter. Dans le cas de l'hébergement de fichiers privés, l'intérêt apparaît clairement. Les équations étant envoyées vers le service de mathjax (si vous l'utilisez directement), celui-ci connait l'intégralité des équations de votre document.

On commence par installer jquery et mathjax

sudo apt install libjs-jquery
sudo apt install libjs-mathjax fonts-mathjax-extras

On crée un virtual host pour apache dans sites-available

<VirtualHost *:80>

ServerName mylibs.mydomain.tld
ServerAdmin webmaster@sciunto.org
ServerAlias mylibs.mydomain.tld
Alias /mathjax/ /usr/share/javascript/mathjax/
Alias /jquery/ /usr/share/javascript/jquery/

ErrorLog ${APACHE_LOG_DIR}/mylibs.mydomain.tld-error.log
CustomLog ${APACHE_LOG_DIR}/mylibs.mydomain.tld-access.log combined

</VirtualHost>

Il est ensuite souhaitable de dupliquer cette configuration en https, ou de n'utiliser que https. letsencrypt permettra d'avoir un certificat pour ça.

Maintenant, dans le code du site web, on peut remplacer l'appel de mathjax (par exemple)

  src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-MML-AM_CHTML"

par

  src="//mylibs.mydomain.tld/mathjax/MathJax.js?config=TeX-AMS-MML_HTMLorMML"

pour le cas d'un appel http ou https ou

  src="https://mylibs.mydomain.tld/mathjax/MathJax.js?config=TeX-AMS-MML_HTMLorMML"

pour un appel en https seulement.

En rédigeant ce billet, je me dis que des hébergeurs comme les CHATONS pourrait aussi proposer ce type de services pour les personnes n'ayant pas la possibilité d'héberger ces bibliothèques.

[raspberry-python] The return of the Los Alamos Memo 10742 -

Publié le 2016-03-05 19:13:00
Modern rendering of the original 1947 Memo 10742

The mathematician prankster


Can you imagine yourself receiving this memo in your inbox in Washington in 1947? There's a certain artistic je ne sais quoi in this memo...

This prank was made by J Carson Mark and Stan Ulam.  A&S was Administration and Services.

And Ulam, well known for working on the Manhattan project, also worked on really interesting things in mathematics. Specifically, a collaboration with Nicholas Constantine Metropolis and John Von Neumann. You might know this as the Monte Carlo method (so named due to Ulam's uncle always asking for money to go and gamble in a Monte Carlo casino...). Some people have learned about a specific Monte Carlo simulation (the first) known as Buffon's needle.

Copying the prankster

When I stumbled upon this many years ago, I decided that it would make a fantastic programming challenge for a workshop and/or class. I first tried it in a Java class, but people didn't get quite into it. Many years later I redid it as part of a weekly Python class I was teaching at a previous employer.

The document is the output of a Python script. In order to make the memo look like it came from the era, I photocopied it. It still didn't look quite right, so I then scanned that into Gimp, bumped the Red and Blue in the color balance tool to give it that stencil / mimeograph / ditto look.


Your assignment


Here is what I asked the students:

"Replicate either:
a) the whole memo
or
b) the list of numbers 
Whichever assignment you choose, the numbers must be generated programmatically."

That was basically it. So, go ahead and try it. In Python. Or in R, or whatever you fancy and post a solution as a comment.

We will come back in some days (so everybody gets a chance to try it) and present some possible methods of doing this. Oh, and why the title of "the return of the Los Alamos Memo"? Well, I noticed I had blogged about it before some years back, but never detailed it...

Learning more on Stan Ulam


See the wikipedia entry and also:

LOS ALAMOS SCIENCE NO. 15, 1987



[EDIT: Part 2 is at: los-alamos-10742-making-of.html]

Francois Dion
@f_dion

[carlchenet] Simplifier la vie de votre community manager avec le projet Twitter Out Of The Browser

Publié le 2016-02-29 23:00:37
Afin d’exister médiatiquement aujourd’hui, il est devenu nécessaire d’être présent sur plusieurs réseaux sociaux. Il faut y apporter quotidiennement du contenu pour espérer construire une audience, et cela sur chacun des ces réseaux sociaux. Heureusement pour vous ou votre community manager, vous pouvez grandement réduire ce travail pour le réseau social Twitter grâce au projet… Continuer de lire Simplifier la vie de votre community manager avec le projet Twitter Out Of The Browser

[ascendances] Des graphiques à la Xkcd

Publié le 2016-02-25 22:26:55
Ou comment faire des graphiques dans le légendaire style de XKCD (une finesse du trait plus tranchante que Michel-Ange, des couleurs plus contrastées que Léonard de Vinci). Les développeurs de Matplotlib l’ont fait et intégré à la bibliothèque. Globalement, il suffit d’initialiser le script python avec la fonction xkcd(). Cette fonction initialise des paramètres pour […]

[AFPy Salt-fr] Compte rendu: Meetup Salt Paris chez D2SI

Publié le 2016-02-22 23:00:00

20h, un soir d'hiver, sous les toits parisiens, un vidéoprojecteur s'allume...

C'est le début du premier meetup Salt de 2016, hébergés et régalés par D2SI, merci à Julien pour son accueil. Nous avons partagé un bon moment dans une ambiance détendue. Suite à pas mal de changements dans le programme, deux présentations:

[sciunto] Contributions #1

Publié le 2016-02-19 23:00:00

Voici une brève d'un certain nombre de mes contributions (les plus abouties) de ces deux derniers mois.

Archlinux

J'ai amélioré l'empaquetage de Dask avec l'ajout de la suite de tests, ce qui m'a demandé d'empaqueter plusieurs autres modules. J'ai dialogué avec le développeur de dask afin d'améliorer la documentation pour les empaqueteurs. Ce module python sera utilisé comme dépendance par défaut de scikit-image. Il est fort à parier que pour la prochaine sortie de scikit-image, le paquet dask passera dans community. Mon travail devrait donc permettre un transfert plus rapide.

J'ai aussi mis à jour pims avec aussi un retour vers le projet ici ou encore à cause d'échecs de tests unitaires.

D'autres paquets ont été mis à jour comme Joblib ou mat.

Jirafeau

Jirafeau est un projet permettant d'héberger des fichiers. J'en héberge une instance sur mon serveur. J'ai contribué à deux petits patchs pour mieux documenter l'API et l'usage du script bash et faciliter la compréhension d'erreurs lors de l'utilisation du script d'envoie. J'ai passé pas mal de temps à résoudre des problèmes sur mon installation et j'espère que cela facilitera l'appropriation de ce code à l'avenir.

Scikit-image

Peu de temps pour contribuer à scikit-image ces temps-ci. Néanmoins, j'ai notamment trouvé une erreur dans la doc que j'ai patché, et ceci avant la sortie d'une version stable. Ca devrait permettre d'éviter de perdre quelques débutants.

Scipy

J'ai rapporté un bug que plusieurs personnes avaient rencontré mais pas remonté. Avec Ralf, on a compris que le bug était déjà réparé dans master (la prochaine fois, je commencerai pas ça) mais ça a au moins eu le mérite de remonter un rapport à pip qui n'affiche plus les informations de compilation depuis 0.8.x, c'est-à-dire l'instauration du spinner. Ce qui est très gênant.

Ikiwiki-pandoc

C'est un projet dont j'assure la maintenance, plus que l'écriture.J'ai eu la chance de pouvoir fusionner les contributions de Baldur qui ont permis de porter le code aux dernières évolutions de pandoc. Je n'ai presque rien fait et je suis heureux de voir qu'avoir regrouper un certain nombre de contributions sur un dépôt mort donne vie au code et que des gens l'utilise.

Gitbackup

Suite au billet de Carl Chenet sur les dangers de github, j'ai décidé de mettre du propre un script que je possédais et qui permet de gérer des miroirs de dépôts git.

Python-bibtexparser

Du travail est en cours sur bibtexparser, grâce à de très belles contributions d'Olivier Mangin pour utiliser pyparsing. Il reste cependant encore du travail pour arriver à la prochaine sortie. Les utilisateurs sont de plus en plus nombreux, ce qui obligent à gérer finement les changements d'API.

share.sciunto.org

Pour la bidouille, j'ai créé une page sur le remplacement d'un couvercle cassé de chambre à vide en verre pour avoir, au final, une étuve à vide fonctionnant à 130°C.

Publication aussi du montage d'un interféromètre de Mach-Zehnder.

Quartzy : fermeture d'un service SaaS

Notre labo utilisait quartzy, un service en ligne permettant de gérer du matériel de laboratoire. Quartzy a décidé de fermer une partie de ses services, dont ceux que nous utilisions. Déjà discuté sur ce blog, la solution que je propose est d'héberger ses services car le SaaS n'assure aucune pérennité, et ceci est un exemple supplémentaire. Un thésard du labo était preneur d'apprendre l'administration système et le webmastering. J'ai donc fait du mentoring pour installer une machine hébergée par l'université et installer un service sur ce serveur. Le choix s'est porté vers un logiciel sous licence GPL. Au passage, ce thésard passe à l'auto-hébergement pour son site web. Une personne sensibilisée et un service libéré.

[cubicweb] Moving forward on CubicWeb development

Publié le 2016-02-08 14:50:00

Some of us at Logilab made some kind of retrospective of the processes surrounding CubicWeb (core) development. One of the important point is that we decided that Logilab would not resume the bi-monthly meetings with other developers and users to discuss and update the roadmap.

Instead, we will do more Blog Driven Development (as started by Denis on this blog) to keep the community up to date with our internal effort. We will continue to use the mailing-list to discuss with everybody what we contribute to CubicWeb.

We will also try to organize a sprint in the coming months, but we are not able to commit on a date for now, because we are under a heavy load with customer work (which is a good thing for us and CubicWeb, of course).

Another topic was to set up a kind of working agreement for those developing on the core. For a start, we agreed on the following points:

  • we stop the two-steps review process
  • integrators commit to handling pending reviews under a 7 days time frame
  • an integrator is not allowed to integrate his or her own patches
  • incoming patches should not make the QA numbers go down, and should be py3k compatible.

QA numbers are still to be defined in a forthcoming internal sprint on continuous integration system. Current integrators are Julien, David, Denis, Florent and Sylvain. If you're interested, let us know on the mailing-list.

[cubicweb] Using JSONAPI as a Web API format for CubicWeb

Publié le 2016-02-08 14:03:00

Following the introduction post about rethinking the web user interface of CubicWeb, this article will address the topic of the Web API to exchange data between the client and the server. As mentioned earlier, this question is somehow central and deserves particular interest, and better early than late. Of the two candidate representations previously identified Hydra and JSON API, this article will focus on the later. Hopefully, this will give a better insight of the capabilities and limits of this specification and would help take a decision, though a similar experiment with another candidate would be good to have. Still in the process of blog driven development, this post has several open questions from which a discussion would hopefully emerge...

A glance at JSON API

JSON API is a specification for building APIs that use JSON as a data exchange format between clients and a server. The media type is application/vnd.api+json. It has a 1.0 version available from mid-2015. The format has interesting features such as the ability to build compound documents (i.e. response made of several, usually related, resources) or to specify filtering, sorting and pagination.

A document following the JSON API format basically represents resource objects, their attributes and relationships as well as some links also related to the data of primary concern.

Taking the example of a Ticket resource modeled after the tracker cube, we could have a JSON API document formatted as:

GET /ticket/987654
Accept: application/vnd.api+json

{
  "links": {
    "self": "https://www.cubicweb.org/ticket/987654"
  },
  "data": {
    "type": "ticket",
    "id": "987654",
    "attributes": {
      "title": "Let's use JSON API in CubicWeb"
      "description": "Well, let's try, at least...",
    },
    "relationships": {
      "concerns": {
        "links": {
          "self": "https://www.cubicweb.org/ticket/987654/relationships/concerns",
          "related": "https://www.cubicweb.org/ticket/987654/concerns"
        },
        "data": {"type": "project", "id": "1095"}
      },
      "done_in": {
        "links": {
          "self": "https://www.cubicweb.org/ticket/987654/relationships/done_in",
          "related": "https://www.cubicweb.org/ticket/987654/done_in"
        },
        "data": {"type": "version", "id": "998877"}
      }
    }
  },
  "included": [{
    "type": "project",
    "id": "1095",
    "attributes": {
        "name": "CubicWeb"
    },
    "links": {
      "self": "https://www.cubicweb.org/project/cubicweb"
    }
  }]
}

In this JSON API document, top-level members are links, data and included. The later is here used to ship some resources (here a "project") related to the "primary data" (a "ticket") through the "concerns" relationship as denoted in the relationships object (more on this later).

While the decision of including or not these related resources along with the primary data is left to the API designer, JSON API also offers a specification to build queries for inclusion of related resources. For example:

GET /ticket/987654?include=done_in
Accept: application/vnd.api+json

would lead to a response including the full version resource along with the above content.

Enough for the JSON API overview. Next I'll present how various aspects of data fetching and modification can be achieved through the use of JSON API in the context of a CubicWeb application.

CRUD

CRUD of resources is handled in a fairly standard way in JSON API, relying of HTTP protocol semantics.

For instance, creating a ticket could be done as:

POST /ticket
Content-Type: application/vnd.api+json
Accept: application/vnd.api+json

{
  "data": {
    "type": "ticket",
    "attributes": {
      "title": "Let's use JSON API in CubicWeb"
      "description": "Well, let's try, at least...",
    },
    "relationships": {
      "concerns": {
        "data": { "type": "project", "id": "1095" }
      }
    }
  }
}

Then updating it (assuming we got its id from a response to the above request):

PATCH /ticket/987654
Content-Type: application/vnd.api+json
Accept: application/vnd.api+json

{
  "data": {
    "type": "ticket",
    "id": "987654",
    "attributes": {
      "description": "We'll succeed, for sure!",
    },
  }
}

Relationships

In JSON API, a relationship is in fact a first class resource as it is defined by a noun and an URI through a link object. In this respect, the client just receives a couple of links and can eventually operate on them using the proper HTTP verb. Fetching or updating relationships is done using the special <resource url>/relationships/<relation type> endpoint (self member of relationships items in the first example). Quite naturally, the specification relies on GET verb for fetching targets, PATCH for (re)setting a relation (i.e. replacing its targets), POST for adding targets and DELETE to drop them.

GET /ticket/987654/relationships/concerns
Accept: application/vnd.api+json

{
  "data": {
    "type": "project",
    "id": "1095"
  }
}

PATCH /ticket/987654/relationships/done_in
Content-Type: application/vnd.api+json
Accept: application/vnd.api+json

{
  "data": {
    "type": "version",
    "id": "998877"
  }
}

The body of request and response of this <resource url>/relationships/<relation type> endpoint consists of so-called resource identifier objects which are lightweight representation of resources usually only containing information about their "type" and "id" (enough to uniquely identify them).

Related resources

Remember the related member appearing in relationships links in the first example?

  [ ... ]
  "done_in": {
    "links": {
      "self": "https://www.cubicweb.org/ticket/987654/relationships/done_in",
      "related": "https://www.cubicweb.org/ticket/987654/done_in"
    },
    "data": {"type": "version", "id": "998877"}
  }
  [ ... ]

While this is not a mandatory part of the specification, it has an interesting usage for fetching relationship targets. In contrast with the .../relationships/... endpoint, this one is expected to return plain resource objects (which attributes and relationships information in particular).

GET /ticket/987654/done_in
Accept: application/vnd.api+json

{
  "links": {
    "self": "https://www.cubicweb.org/998877"
  },
  "data": {
    "type": "version",
    "id": "998877",
    "attributes": {
        "number": 4.2
    },
    "relationships": {
      "version_of": {
        "self": "https://www.cubicweb.org/998877/relationships/version_of",
        "data": { "type": "project", "id": "1095" }
      }
    }
  },
  "included": [{
    "type": "project",
    "id": "1095",
    "attributes": {
        "name": "CubicWeb"
    },
    "links": {
      "self": "https://www.cubicweb.org/project/cubicweb"
    }
  }]
}

Meta information

The JSON API specification allows to include non-standard information using a so-called meta object. This can be found in various place of the document (top-level, resource objects or relationships object). Usages of this field is completely free (and optional). For instance, we could use this field to store the workflow state of a ticket:

{
  "data": {
    "type": "ticket",
    "id": "987654",
    "attributes": {
      "title": "Let's use JSON API in CubicWeb"
    },
    "meta": { "state": "open" }
}

Permissions

Permissions are part of metadata to be exchanged during request/response cycles. As such, the best place to convey this information is probably within the headers. According to JSON API's FAQ, this is also the recommended way for a resource to advertise on supported actions.

So for instance, response to a GET request could include Allow headers, indicating which request methods are allowed on the primary resource requested:

GET /ticket/987654
Allow: GET, PATCH, DELETE

An HEAD request could also be used for querying allowed actions on links (such as relationships):

HEAD /ticket/987654/relationships/comments
Allow: POST

This approach has the advantage of being standard HTTP, no particular knowledge of the permissions model is required and the response body is not cluttered with these metadata.

Another possibility would be to rely use the meta member of JSON API data.

{
  "data": {
    "type": "ticket",
    "id": "987654",
    "attributes": {
      "title": "Let's use JSON API in CubicWeb"
    },
    "meta": {
      "permissions": ["read", "update"]
    }
  }
}

Clearly, this would minimize the amount client/server requests.

More Hypermedia controls

With the example implementation described above, it appears already possible to manipulate several aspects of the entity-relationship database following a CubicWeb schema: resources fetching, CRUD operations on entities, set/delete operations on relationships. All these "standard" operations are discoverable by the client simply because they are baked into the JSON API format: for instance, adding a target to some relationship is possible by POSTing to the corresponding relationship resource something that conforms to the schema.

So, implicitly, this already gives us a fairly good level of Hypermedia control so that we're not so far from having a mature REST architecture according to the Richardson Maturity Model. But beyond these "standard" discoverable actions, the JSON API specification does not address yet Hypermedia controls in a generic manner (see this interesting discussion about extending the specification for this purpose).

So the question is: would we want more? Or, in other words, do we need to define "actions" which would not map directly to a concept in the application model?

In the case of a CubicWeb application, the most obvious example (that I could think of) of where such an "action" would be needed is workflow state handling. Roughly, workflows in CubicWeb are modeled through two entity types State and TrInfo (for "transition information"), the former being handled through the latter, and a relationship in_state between the workflowable entity type at stake and its current State. It does not appear so clearly how would one model this in terms of HTTP resource. (Arguably we wouldn't want to expose the complexity of Workflow/TrInfo/State data model to the client, nor can we simply expose this in_state relationship, as a client would not be able to simply change the state of a entity by updating the relation). So what would be a custom "action" to handle the state of a workflowable resource? Back in our tracker example, how would we advertise to the client the possibility to perform "open"/"close"/"reject" actions on a ticket resource? Open question...

Request for comments

In this post, I tried to give an overview of a possible usage of JSON API to build a Web API for CubicWeb. Several aspects were discussed from simple CRUD operations, to relationships handling or non-standard actions. In many cases, there are open questions for which I'd love to receive feedback from the community. Recalling that this topic is a central part of the experiment towards building a client-side user interface to CubicWeb, the more discussion it gets, the better!

For those wanting to try and play themselves with the experiments, have a look at the code. This is a work-in-progress/experimental implementation, relying on Pyramid for content negotiation and route traversals.

What's next? Maybe an alternative experiment relying on Hydra? Or an orthogonal one playing with the schema client-side?

[cubicweb] Status of the CubicWeb python3 porting effort, February 2016

Publié le 2016-02-05 16:03:00

An effort to port CubicWeb to a dual python 2.6/2.7 and 3.3+ code base was started by Rémi Cardona in summer of 2014. The first task was to port all of CubicWeb's dependencies:

  • logilab-common 0.63
  • logilab-database 1.14
  • logilab-mtconverter 0.9
  • logilab-constraint 0.6
  • yams 0.40
  • rql 0.34

Once that was out of the way, we could start looking at CubicWeb itself. We first set out to make sure we used python3-compatible syntax in all source files, then started to go and make as much of the test suite as possible pass under both python2.7 and python3.4. As of the 3.22 release, we are almost there. The remaining pain points are:

  • cubicweb's setup.py hadn't been converted. This is fixed in the 3.23 branch as of https://hg.logilab.org/master/cubicweb/rev/0b59724cb3f2 (don't follow that link, the commit is huge)
  • the CubicWebServerTC test class uses twisted to start an http server thread, and twisted itself is not available for python3
  • the current method to serialize schema constraints into CWConstraint objects gives different results on python2 and python3, so it needs to be fixed (https://www.logilab.org/ticket/296748)
  • various questions around packaging and deployment: what happens to e.g. the cubicweb-common package installing into python2's site-packages directory? What does the ${prefix}/share/cubicweb directory become? How do cubes express their dependencies? Do we need a flag day? What does that mean for applications?

[sciunto] gitbackup : maintenir une copie conforme (miroir) d'un dépôt git

Publié le 2016-01-28 23:00:00

Problématique

J'ai déjà argumenté à plusieurs reprises du risque que l'on prend à utiliser des systèmes que nous ne gérons pas nous même, comme github (ref). Cette problématique fonctionne aussi pour des dépôts maintenus par des personnes qui peuvent avoir envie de supprimer les données, bien que vous les trouviez intéressantes. Mêmes arguments pour des organisations comme framasoft ou FFDN. Ainsi, je ne peux qu'encourager à avoir son propre serveur git, pour les dépôts privés, mais aussi pour les miroirs. Le Logiciel Libre a la copie dans son génome, utilisons-le.

Principe

J'ai appris comment faire proprement un miroir d'un dépôt sur la doc de github.

# On clone le depot sur github
git clone --mirror https://github.com/exampleuser/repository-to-mirror.git

cd repository-to-mirror.git
# On ajoute comme destination chezmoi.org
git remote set-url --push origin https://git.chezmoi.org/exampleuser/mirrored

# On pousse
git push --mirror

A intervalle régulier, on peut faire

git fetch -p origin
git push --mirror

L'avantage est qu'on synchronise toutes les branches et les tags, mais on ne synchronise pas les tickets.

gitbackup

Pour tout dire, ce billet trainait dans mon dossier en préparation. J'utilisais un petit script et suite à l'article de Carl Chenet et repris sur framablog, je me suis convaincu qu'un code propre pouvait être utile à d'autre. Comme le dit Benjamin Bayart, il faut faire !. En quelques bouts de soirées, j'ai tenté de mettre les choses au propre.

Le but est d'avoir un outil proche de git d'un point de vue syntaxique pour automatiser les commandes ci-dessus. J'ai aussi gardé le même format (configparse) pour le fichier de configuration.

# On se crée un chez soi
mkdir backup_github && cd backup_github

# On initialise
gitbackup init

# On clone deux dépôts dont on veut un miroir
gitbackup clone sametmax_0bin https://github.com/sametmax/0bin.git

gitbackup clone carl_backupchecker https://github.com/backupchecker/backupchecker.git

# Quand les développeurs auront fait évolué le projet,
# on pourra synchroniser les changements
# sur un dépôt spécifique
gitbackup pull sametmax_0bin

# ou sur tous les dépôts
gitbackup pull

Le code est sur github (sinon, ce ne serait pas drôle) en GPLv3.

Sous peu, je vais ajouter une fonctionnalité pour ajouter un remote afin de pousser le miroir sur un autre site. Je vais pousser le code sur pipy, et faire un paquet pour archlinux.

C'est libre, ce code est aussi le votre. Commentaires et surtout pull requests sont les bienvenus.

[cubicweb] Towards building a JavaScript user interface to CubicWeb

Publié le 2016-01-27 22:15:00

This post is an introduction of a series of articles dealing with an on-going experiment on building a JavaScript user interface to CubicWeb, to ultimately replace the web component of the framework. The idea of this series is to present the main topics of the experiment, with open questions in order to eventually engage the community as much as possible. The other side of this is to experiment a blog driven development process, so getting feedback is the very point of it!

As of today, three main topics have been identified:

  • the Web API to let the client and server communicate,
  • the issue of representing the application schema client-side, and,
  • the construction of components of the web interface (client-side).

As part of the first topic, we'll probably rely on another experimental work about REST-fulness undertaken recently in pyramid-cubicweb (see this head for source code). Then, it appears quite clearly that we'll need sooner or later a representation of data on the client-side and that, quite obviously, the underlying format would be JSON. Apart from exchanging of entities (database) information, we already anticipate on the need for the HATEOAS part of REST. We already took some time to look at the existing possibilities. At a first glance, it seems that hydra is the most promising in term of capabilities. It's also built using semantic web technologies which definitely grants bonus point for CubicWeb. On the other hand, it seems a bit isolated and very experimental, while JSON API follows a more pragmatic approach (describe itself as an anti-bikeshedding tool) and appears to have more traction from various people. For this reason, we choose it for our first draft, but this topic seems so central in a new UI, and hard to hide as an implementation detail; that it definitely deserves more discussion. Other candidates could be Siren, HAL or Uber.

Concerning the schema, it seems that there is consensus around JSON-Schema so we'll certainly give it a try.

Finally, while there is nothing certain as of today we'll probably start on building components of the web interface using React, which is also getting quite popular these days. Beyond that choice, the first practical task in this topic will concern the primary view system. This task being neither too simple nor too complicated will hopefully result in a clearer overview of what the project will imply. Then, the question of edition will come up at some point. In this respect, perhaps it'll be a good time to put the UX question at a central place, in order to avoid design issues that we had in the past.

Feedback welcome!

[cubicweb] Happy New Year CubicWeb !

Publié le 2016-01-25 14:30:00

This CubicWeb blog that has been asleep for some months, whereas the development was active. Let me try to summarize the recent progress.

https://upload.wikimedia.org/wikipedia/commons/thumb/f/f1/New_Year_Ornaments_%282%29.JPG/320px-New_Year_Ornaments_%282%29.JPG

CubicWeb 3.21

CubicWeb 3.21 was published in July 2015. The announce was sent to the mailing list and changes were listed in the documentation.

The main goal of this release was to reduce the technical debt. The code was improved, but the changes were not directly visible to users.

CubicWeb 3.22

CubicWeb 3.22 was published in January 2016. A mail was sent to the mailing list and the documentation was updated with the list of changes.

The main achievements of this release were the inclusion of a new procedure to massively import data when using a Postgresql backend, improvements of migrations and customization of generic JSON exports.

Roadmap and bi-monthly meetings

After the last-minute cancellation of the may 2015 roadmap meeting, we failed to reschedule in june, the summer arrived, then the busy-busy end of the year... and voilà, we are in 2016.

During that time, Logilab has been working on massive data import, full-js user interfaces exchanging JSON with the CubicWeb back-end, 3D in the browser, switching CubicWeb to Python3, moving its own apps to Bootstrap, using CubicWeb-Pyramid in production and improving management/supervision, etc. We will be more than happy to discuss this with the rest of the (small but strong) CubicWeb community.

So let's wish a happy new year to everyone and meet again in March for a new roadmap session !

[sciunto] Don du mois : debian

Publié le 2016-01-23 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.

Le don de ce mois est pour debian. J'utilise cet OS pour mes serveurs. J'ai bien essayé pour les stations de travail, mais la lenteur de l'évolution de debian m'a fait reculer pour préférer archlinux auquel j'ai déjà consacré un don. Néanmoins, debian est une distribution de choix pour les serveurs. C'est stable, c'est documenté, la communauté est active et les mises à jours sont de qualité. Donc 15$ pour debian.

Pour faire un don à debian

[carlchenet] Le danger Github

Publié le 2016-01-21 23:00:35
Suivez-moi aussi sur Diaspora* ou Twitter  Alors que le projet CPython (implémentation historique du projet Python) a annoncé son passage chez Github (avec quelques restrictions, nous reviendrons là-dessus), il est plus que jamais important de s’interroger sur les risques encourus d’utiliser un logiciel propriétaire dans notre chaîne de création du Logiciel Libre. Des voix critiques… Continuer de lire Le danger Github

[AFPy Salt-fr] Compte rendu (sommaire) du meetup Salt Paris de décembre 2015

Publié le 2016-01-19 23:00:00

Le jeudi 17 decembre 2015, comme annoncé, une partie de la communauté Salt s'est réuni autour de trois présentation dans les locaux de Vivendi / Canal+.

Retour d'expérience : Un peu de sel pour être HAPI - Metin OSMAN (Canal+)

Metin Osman nous a présenté un retour d’expérience sur l'utilisation de Salt à Canal+ avec un peu de fabric, jenkins, git et des syndics Salt (mais aussi elasticsearch, logstash, redis, nginx, etc.). Prochainement ils espèrent utiliser gitfs et docker. La présentation est disponible sur slideshare.

La supervision pilotée par Salt avec carbon/graphite/grafana - Arthur Lutz (Logilab)

Salt Meetup

Arthur Lutz a présenté une démo dans des docker (lancés par docker-compose) en montant une architecture frontal+application+base de données et en supervisant le tout avec Salt. Les résultats de la supervision sont stockés dans un graphite (bases temporelles whisper) et des tableaux de bord sont construits en utilisant grafana. La démo est disponible dans un dépôt mercurial sur bitbucket (salt_graphite_grafana). Quelques slides pour introduire le tout sont aussi publiés.

Salt + Graphite + Grafana

Une interface web open-source pour Salt avec SaltPad v.2 en ReactJS - Boris Feld (tinyclues)

Boris a présenté la nouvelle version de SaltPad en ReactJS (la précédente version était en Flask) https://github.com/tinyclues/saltpad/

Saltpad screenshot

Nous aurons peut-être, dans les prochaines semaines, une vidéo montée par Julien de Canal+.

Update : voici les vidéos, merci à Julien.

Merci à Canal+ / Vivendi pour le lieu. Merci à Logilab pour les pizzas & bières.

La suite : un meetup en février ?

[carlchenet] Feed2tweet 0.2 : pouvoir de la ligne de commande

Publié le 2016-01-13 23:00:12
Feed2tweet a été publié en version 0.2 ! Cette application prend en entrée un flux RSS et envoie les différentes entrées sur le réseau social Twitter. Elle est auto-hébergée, codée en Python 3, sous licence GPLv3 et documentée. Feed2tweet sur Github (étoiles appréciées, ça augmente la visibilité du projet) Feed2tweet sur Readthedocs Feed2tweet est déjà… Continuer de lire Feed2tweet 0.2 : pouvoir de la ligne de commande