Planète AFPy RSS

[afpy.org] PyData Paris 12-13 juin 2017 : l'appel à conférencier est ouvert jusqu'au 17 avril

Publié le 2017-04-08 06:02:28

[cubicweb] Hypermedia API with cubicweb-jsonschema

Publié le 2017-04-04 13:20:00

This is the second post of a series about cubicweb-jsonschema. The first post mainly dealt with JSON Schema representations of CubicWeb entities along with a brief description of the JSON API. In this second post, I'll describe another aspect of the project that aims at building an hypermedia API by leveraging the JSON Hyper Schema specification.

Hypermedia APIs and JSON Hyper Schema

Hypermedia API is somehow a synonymous of RESTful API but it makes it clearer that the API serves hypermedia responses, i.e. content that helps discoverability of other resources.

At the heart of an hypermedia API is the concept of link relation which both aims at describing relationships between resources as well as provinding ways to manipulate them.

In JSON Hyper Schema terminology, link relations take the form of a collection of Link Description Objects gathered into a links property of a JSON Schema document. These Link Description Objects thus describes relationships between the instance described by the JSON Schema document at stake and other resources; they hold a number of properties that makes relationships manipulation possible:

  • rel is the name of the relation, it is usually one of relation names registered at IANA;
  • href indicates the URI of the target of the relation, it may be templated by a JSON Schema;
  • targetSchema is a JSON Schema document (or reference) describing the target of the link relation;
  • schema (recently renamed as submissionSchema) is a JSON Schema document (or reference) describing what the target of the link expects when submitting data.

Hypermedia walkthrough

In the remaining of the article, I'll walk through a navigation path that is made possible by hypermedia controls provided by cubicweb-jsonschema. I'll continue on the example application described in the first post of the series which schema consists of Book, Author and Topic entity types. In essence, this walkthrough is typical of what an intelligent client could do when exposed to the API, i.e. from any resource, discover other resources and navigate or manipulate them.

This walkthrough assumes that, given any resource (i.e. something that has a URL like /book/1), the server would expose data at the main URL when the client asks for JSON through the Accept header and it would expose the JSON Schema of the resource at a schema view of the same URL (i.e. /book/1/schema). This assumption can be regarded as a kind of client/server coupling, which might go away in later implementation.

Site root

While client navigation could start from any resource, we start from the root resource and retrieve its schema:

GET /schema
Accept: application/schema+json

HTTP/1.1 200 OK
Content-Type: application/json

{
    "links": [
        {
            "href": "/author/",
            "rel": "collection",
            "schema": {
                "$ref": "/author/schema?role=creation"
            },
            "targetSchema": {
                "$ref": "/author/schema"
            },
            "title": "Authors"
        },
        {
            "href": "/book/",
            "rel": "collection",
            "schema": {
                "$ref": "/book/schema?role=creation"
            },
            "targetSchema": {
                "$ref": "/book/schema"
            },
            "title": "Books"
        },
        {
            "href": "/topic/",
            "rel": "collection",
            "schema": {
                "$ref": "/topic/schema?role=creation"
            },
            "targetSchema": {
                "$ref": "/topic/schema"
            },
            "title": "Topics"
        }
    ]
}

So at root URL, our application serves a JSON Hyper Schema that only consists of links. It has no JSON Schema document, which is natural since there's usually no data bound to the root resource (think of it as empty rset in CubicWeb terminology).

These links correspond to top-level entity types, i.e. those that would appear in the default startup page of a CubicWeb application. They all have "rel": "collection" relation name (this comes from RFC6573) as their target is a collection of entities. We also have schema and targetSchema properties.

From collection to items

Now that we have added a new book, let's step back and use our books link to retrieve data (verb GET):

GET /book/
Accept: application/json

HTTP/1.1 200 OK
Allow: GET, POST
Content-Type: application/json

[
    {
        "id": "859",
        "title": "L'homme qui rit"
    },
    {
        "id": "858",
        "title": "The Old Man and the Sea"
    },
]

which, as always, needs to be completed by a JSON Schema:

GET /book/schema
Accept: application/schema+json


HTTP/1.1 200 OK
Content-Type: application/json

{
    "$ref": "#/definitions/Book_plural",
    "definitions": {
        "Book_plural": {
            "items": {
                "properties": {
                    "id": {
                        "type": "string"
                    },
                    "title": {
                        "type": "string"
                    }
                },
                "type": "object"
            },
            "title": "Books",
            "type": "array"
        }
    },
    "links": [
        {
            "href": "/book/",
            "rel": "collection",
            "schema": {
                "$ref": "/book/schema?role=creation"
            },
            "targetSchema": {
                "$ref": "/book/schema"
            },
            "title": "Books"
        },
        {
            "href": "/book/{id}",
            "rel": "item",
            "targetSchema": {
                "$ref": "/book/schema?role=view"
            },
            "title": "Book"
        }
    ]
}

Consider the last item of links in the above schema. It has a "rel": "item" property which indicates how to access items of the collection; its href property is a templated URI which can be expanded using instance data and schema (here we only have a single id template variable).

So our client may navigate to the first item of the collection (id="859") at /book/859 URI, and retrieve resource data:

GET /book/859
Accept: application/json

HTTP/1.1 200 OK
Allow: GET, PUT, DELETE
Content-Type: application/json

{
    "author": [
        "Victor Hugo"
    ],
    "publication_date": "1869-04-01T00:00:00",
    "title": "L'homme qui rit"
}

and schema:

GET /book/859/schema
Accept: application/schema+json

HTTP/1.1 200 OK
Content-Type: application/json

{
    "$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"
        }
    },
    "links": [
        {
            "href": "/book/",
            "rel": "up",
            "targetSchema": {
                "$ref": "/book/schema"
            },
            "title": "Book_plural"
        },
        {
            "href": "/book/859/",
            "rel": "self",
            "schema": {
                "$ref": "/book/859/schema?role=edition"
            },
            "targetSchema": {
                "$ref": "/book/859/schema?role=view"
            },
            "title": "Book #859"
        }
    ]
}

Entity resource

The resource obtained above as an item of a collection is actually an entity. Notice the rel="self" link. It indicates how to manipulate the current resource (i.e. at which URI, using a given schema depending on what actions we want to perform). Still this link does not indicate what actions may be performed. This indication is found in the Allow header of the data response above:

Allow: GET, PUT, DELETE

With these information bits, our intelligent client is able to, for instance, form a request to delete the resource. On the other hand, the action to update the resource (which is allowed because of the presence of PUT in Allow header, per HTTP semantics) would take the form of a request which body conforms to the JSON Schema pointed at by the schema property of the link.

Also note the rel="up" link which makes it possible to navigate to the collection of books.

Conclusions

This post introduced the main hypermedia capabilities of cubicweb-jsonschema, built on top of the JSON Hyper Schema specification. The resulting Hypermedia API makes it possible for an intelligent client to navigate through hypermedia resources and manipulate them by using both link relation semantics and HTTP verbs.

In the next post, I'll deal with relationships description and manipulation both in terms of API (endpoints) and hypermedia representation.

[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

Développeu.r.se Fullstack

CDI au sein d'une équipe de 11 personnes en plein Bordeaux.

#TDD #Python #Linux #ES6 #extremeprogramming

Yaal cherche un|e développeu|r|se pour agrandir son équipe !

Dans une ambiance collaborative et une équipe autogérée, vous avez accès à l'ensemble d'un projet informatique complexe ; de la conception à la livraison en production.

Possibilité très forte de rentrer au capital de la société. Yaal est composé à 60% de salariés-associés.

Nous souhaitons développer dans les meilleures conditions :

  • En équipe plutôt que seul ;
  • En autonomie plutôt qu'en subordination ;
  • Sur du bon matériel plutôt que sur une machine premier prix avec un écran 15 pouces ;
  • Dans de bonnes conditions environnementales (local proche de la victoire, salle de repos) ;
  • Avec une ambiance bienveillante !
  • En maximisant notre plaisir au travail !

Nos contributions:

Disponibles sur https://yaal.fr/contributions

Yaal sponsorise et participe à plusieurs évènements informatiques dans toute la France.

  • Rémunération : 25 K€ - 35 K€
  • Lieu : Bordeaux Victoire
  • Poste à pourvoir : Immédiatement.
  • Contrat : CDI 35h.

Envoyer votre candidature à : contact@yaal.fr ou passez nous voir !

Nos plus:

  • Mutuelle 100% d'entreprise !
  • Tickets restos.
  • Vélo d'entreprise !
  • Téléphone portable !
  • Ordinateur portable !
  • Café (en grain !) à volonté.
  • PS4/Jeux de plateaux/Imprimante 3D...
  • Vegan Friendly
  • PC fixe sur mesure !

Retrouvez le récapitulatif de l'annonce au format pdf ici !

[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

[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

[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

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

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

[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?

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

[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

[Yaal] Les nouveautés de notre bibliothèque partagée, Livres de Proches

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

On vous l’annonçait il y a quelques semaines, livresdeproches.fr faisait sa première sortie en public. Communication plutôt discrète dans un premier temps, nous voulions faire évoluer le site et ses fonctionnalités afin de vous proposer une expérience des plus plaisantes.

Mais Livres de Proches c’est quoi ?

Produit d’une réflexion d’équipe et d’un désir de faciliter l’échange autour de la lecture, c’est un projet qui nous tient à coeur. Son but est de vous proposer une plateforme virtuelle afin de partager avec vos proches, vos livres et vos lectures. Nous souhaitions toucher tous les « amoureux » de la lecture et leur apporter un outil facile d’utilisation au quotidien. Que vous soyez collectionneur, blogueur, ou simple passionné de livre, livresdeproches.fr est fait pour vous. Dotée d’une interface claire et simple, organiser sa bibliothèque virtuelle, partager ses livres, emprunter les livres de ses proches ou de son réseau et suivre votre compte n’a jamais été aussi simple.

Vous êtes blogueur et vous avez des livres à recommander ? Regroupez-les tous sur livresdeproches.fr et permettez à vos lecteurs de les retrouver facilement à un seul endroit ou sur vos différents sites web et blogs personnels grâce à l’utilisation de l’iframe et actualisez votre contenu en quelques clics.

Collectionneur ? Listez facilement tous vos livres en un seul endroit et gérez toute votre bibliothèque facilement. Vous pouvez aussi annoter vos différents ouvrages grâce à l'ajout et l'édition manuelle et entrez-y les détails qui vous semblent important.

Ou vous aimez tout simplement lire et découvrir chaque jour de nouvelles lectures ? Livresdeproches.fr vous offrira bientôt la possibilité de vous rapprocher de vos proches ou de vos amis grâce aux réseaux sociaux ou une simple adresse email afin d’emprunter leurs livres. Vous pourrez également gérer des communautés et regrouper les personnes qui partagent les mêmes goûts que vous dans des espaces dédiés.

Beaucoup d’autres fonctionnalités sont en préparation, toujours dans le but de vous offrir le meilleur de la plateforme. Vous découvrirez bientôt l’ajout de livre grâce au scan de code barre afin de vous permettre de remplir votre bibliothèque encore plus rapidement. Bientôt, personnalisez votre profil et partagez via les réseaux sociaux vos étagères. Suivez les bibliothèques des personnes qui vous intéressent.

Toutes ces évolutions et améliorations seront bientôt disponibles sur livresdeproches.fr mais vous pouvez dès à présent créer votre compte, remplir vos étagères virtuelles et découvrir la plateforme. Soucieux de respecter nos utilisateurs, la plateforme est gratuite et nous mettons un point d’honneur à respecter votre vie privée.

Tous les avis et retours, qu’ils soient positifs ou négatifs sont les bienvenus. Nous souhaitons vraiment que cette plateforme devienne la vôtre et vous proposer la meilleure expérience utilisateur !

Écrivez-nous !

À très bientôt sur livresdeproches.fr

[raspberry-python] Raspberry #PiZero & MagP1

Publié le 2015-12-27 16:22:00
Royal Mail
Antistatic
MagPi
Camo
#PiZero

Francois Dion
@f_dion

[encolpe] When UnicodeDecodeError become irrational check $LANG

Publié le 2015-12-12 15:54:25
I spent hours this week trying to understand how an installation script can fail on some installations. In input we have an utf-8 encoded file and we add some xml files, also ‘utf-8’ encoded. These are parsed with Markdown. python -m lom2mlr.markdown -l -c rationale.md It is really simple but sometimes we ran into a […]

[Yaal] Surfrider Open Campus, ouvert !

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

Il y a déjà un an Yaal a été choisi par Surfrider Foundation Europe pour assurer les aspects graphiques et techniques d’un nouveau projet d’envergure baptisé Open Campus. Aujourd’hui nous sommes fiers de vous annoncer la sortie de cette plateforme et par cette occasion opportune vous en parler plus en détail.

Page d'accueil Open Campus

L’association Surfrider est née d’une volonté de sensibiliser le public aux problèmes environnementaux qui menacent l’océan et le littoral. Au sein de Surfrider le Campus c’est leur centre d'éducation et de formation au développement durable. Il en existe plusieurs expressions. Le Campus In étant orienté sur des activités (expositions, conférences, débats…) dans leurs locaux et le Campus Out sur des interventions sur le terrain (ramassage de déchets sur la plage) ou bien dans les écoles. Mais jusqu’à présent il n’existait pas de véritable plateforme d’e-éducation. Open Campus est la réponse à ce manque.

Aspects phares du projet

Apprendre :
On peut suivre des cours allant du niveau débutant jusqu’à avancé sur six thématiques différentes. Un cours est divisé en plusieurs chapitres dans lequel on peut retrouver une variété de contenus tel que du texte, des vidéos, des images et des quiz. Les quiz permettent, à travers trois types de questions (réponse à choix multiple, réponse libre et texte à trous), de tester ses connaissances par rapport au sujet donné.

Page d'apprendre Open Campus

Quiz multijoueurs :
Pour utiliser les quiz dans un contexte de groupe un mode multijoueur a été développé. Un professeur, par exemple, peut initier un quiz pour ses élèves lors d’un cours sur un sujet tel que les déchets aquatiques. Les élèves, munis de tablettes, smartphones ou ordinateurs, peuvent répondre aux questions et voir les points gagnés au fur et à mesure de l’avancement. Un gagnant est désigné à la fin.

Quiz multijoueur sur telephone

Contribuer :
En plus des quiz proposés par Surfrider il est aussi possible pour les utilisateurs du site de créer leurs propres quiz. Ils peuvent même les rendre public afin d’en faire profiter la communauté. Une interface dédiée permet de voir ses quiz, ses favoris et ses quiz multijoueurs.

Ressources :
En complément des cours il existe aussi de nombreuses ressources vidéos.

Conclusion

Pour nous le point fort de ce projet c’est l’association réussite entre un graphisme sobre et efficace (merci Marianne), une interface fluide (merci ReactJS) et responsive et un back-end sur mesure (merci Stéphane). C’est cette association qui nous a permis de répondre efficacement au besoin que Surfrider nous a communiqué. Par ailleurs, nous avons pris plaisir à travailler sur un projet avec des valeurs qui sont en accord avec celles des membres de Yaal.

Bon lancement à Open Campus !

[afpyro] AFPYro à Nantes - Vendredi 27 novembre

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

Avant de commencer l’AFPy Camp rien de tel qu’un petit AFPYro pour faire connaissance.

Rendez-vous à 20h vendredi soir devant le 37bis quai de Versailles à Nantes pour partir manger ensemble.

[Yaal] Agitation de particules démocratiques

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

Nous venons de consacrer deux jours en équipe, accompagnés par un facilitateur externe, pour prendre un pas de recul sur notre modèle organisationnel. Je suis fier de la manière dont nous avons réussi à reformuler notre projet : permettre à chaque équipier de s'émanciper et j'apprécie aussi la formulation de notre stratégie organisationnelle : à chacun de faire vivre les dynamiques qu'il aime.

Cela fait déjà longtemps que nous progressons petit à petit dans cette voie, mais avoir su formuler aussi simplement ce que nous faisions et se confirmer mutuellement que c'est bien ce que que nous voulons, soude l'équipe et nous donne envie de continuer l'aventure !

Il faut bien sûr savoir étayer ces intentions par des pratiques, puisées par-ci par-là, évaluées concrètement, adaptées, abandonnées ou finalement appréciées et soutenues.

Aujourd'hui chez Yaal, à titre d'exemple, nous faisons vivre les pratiques suivantes :

  • nous réunir pour piloter les activités tous les lundis matins, façon GTD, sur un tableau Trello ;
  • faire suivre cette réunion par des conversations libres, ad lib, avec un bâton de parole ;
  • brainstormer pour les sujets particulièrement complexes ;
  • faire tourner ses doigts pour montrer que l'on veut avancer en réunion, pratique essentielle s'il en est ;
  • fournir une évaluation du temps passé en clôture des activités ROTI ;
  • satisfaire dans le temps le plus court les expressions de besoin (Lead Time) ;
  • avoir peu de sujets importants simultanément ;
  • prendre des décisions rapidement par Decider ;
  • etc.

Nous avons décidé lors de ces deux jours d'ajouter à cette liste :

  • faire appel à un facilitateur interne pour les sujets compliqués ;
  • faire appel régulièrement (annuellement ?) à un facilitateur externe ;
  • ralentir pour prendre les décisions importantes par consentement.

Et puis, une nouvelle pratique que je voudrais faire vivre :

  • la Communication Non Violente, pouvant se définir comme « le langage et les interactions qui renforcent notre aptitude à donner avec bienveillance et à inspirer aux autres le désir d'en faire autant ».

Un grand merci à notre facilitateur, que dis-je, à notre agitateur de particules démocratiques, qui, entre échauffements physiques et jeux de communication, a su nous faire travailler sur notre modèle, ouvrir les débats catalyseurs de changement et accompagner leur résolution avec subtilité. Le tout dans le respect de chacun et de notre projet collectif !

[Yaal] Un mois de conférences

Publié le 2015-11-17 23:00:00

Grâce à Yaal, j'ai pu participer à pas moins de trois conférences en un mois \o/

Pytong

Pytong est une petite conférence autour de python qui s'est déroulée à Lyon. Nous étions sponsor de l'édition :) Avec mes collègues Stéphane et Bruno, nous avons pu discuter sur deux jours avec d'autres professionnels experts et passionnés utilisant python dans un contexte web au quotidien. L'occasion de discuter des nouveaux outils et de l'évolution de l'écosystème Python.

On a pu y voir (entre autre):

EventSources ou SSE, les web-sockets en read-only

EventSource un protocole comme WebSocket plus simple (en lecture seule). Attention il y a une limite sur le nombre de connexions simultanées (nombre d'onglets ouverts limités). La présentation était un premier retour d'expérience de Pierre-Yves Chibon plutôt convaincant. Il ne reste plus qu'aux différents navigateurs de se mettre à la page !

Gestion de ses dépendances

Un présentation complète dispensé par Arthur Vuillard le co-organisateur de la pytong et gentil animateur de la journée :). (Les slides sont par ici.) Un rappel de la approuved façon de gérer les numéros de version (PEP440). J'en ai surtout retenu que l'on peut (avec de la confiance) borner les versions dans les fichiers requirements.txt plutôt que les fixer afin d'avoir les dernières corrections. Par exemple : requests >= 2.0, < 3.0 ou requests >= 2.0, == 2.* ou requests ~= 2.7

Mock considered harmful

Une présentations à charge sur les mocks. Verdict : ils sont nuisibles au refactoring et cachent des bugs. Donc à éviter quand c'est possible ! (utilisation de stubs dans la conf). Nous sommes arrivés au même constat par la pratique (et la douleur). Cette présentation et le débat qui a suivi m'a motivé pour présenter notre façons de tester chez Yaal. Donc merci à Boris Feld @lothiraldan !

Rendre son code lisible

Xavier Ordoquy @linovia_net nous a montré une présentation en francais basée sur The Clean Architecture de Brandon Rhodes. On approuve pas mal, mieux : on pratique. :)

Du site dynamique au document imprimable en Python

Enfin on a terminé par une présentation de WeasyPrint par Guillaume Ayoub. Le but : imprimer des pages HTML en utilisant la spéc CSS pour le print. Une présentation très sympa par quelqu'un de très calé sur le sujet :). On a quand même tristement conclu que l'impression finale nécessite quand même de bien configurer l'imprimante.

Les ateliers

Au format libre, on a parlé de tests, et d'outils :

Le dimanche matin

Après une soirée arrosée et bien remplie dans un bouchon lyonnais, on a joué à Symbioz, un jeu très sympa dont la version 2.0 est en prototypage par l'auteur. Un concept d'écosystème simple, mais difficile à gérer. On a également beta-testé un jeu basé sur les châteaux de la renaissance : Artigiano crée par Céline Dumas avec la collaboration de Guillaume Ayoub. Un jeu sous license Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 3.0 France. Une mécanique de jeu à base de pile très efficace !

BDX.io

Co-organisateur de la précédente édition, j'étais cette fois-ci encadrant en soutien pour gérer l'accueil des 512 participants ! Bdx.io est la plus grosse conférence dédiée au développement sur Bordeaux tant en nombre de participants qu'en nombre de conférenciers. Plus de 40 conférences ! Je n'ai pu regarder que les conférences de l'après midi :

Créer son blog en 5 minutes et publier en Asciidoc !

Une présentation par Benoit Prioux @binout qui tient d'ailleurs son blog à l'aide de hubpress.io, avis aux adeptes de github et d'asciidoc !

Moi je code ma doc

Par Mehdi Rebiai. Cette présentation m'a permis de découvrire PlantUML et franchement pour la préparation des cours, formations ou autres doc, c'est cool !

« No one at google uses MapReduce anymore » - Cloud Dataflow explained for dummies

Une présentation rondement menée par Martin Gorner « Google Developer Relations » et Didier Girard une bonne pub/démo des capacités de Google cloud dataflow

Vers une architecture de microservices

Un retour d'expérience et une présentation live de Stéphane Lagraulet et Olivier Revial d'Ippon technologie, sur la mise en place d'une architecture de microservices face à un code legacy monolitique. Et un live coding sur toute la stack netflix.

La keynote de fin

Pilotée par Thomas Parisot sur une question très technique : monolithe ou microservices. Il a beaucoup été question de bonheur au travail et de bonheur personnel. Une keynote philosophique qui tranche avec le sérieux technique de la journée.

Agile Tour Bordeaux

Après avoir été co-organisateur en 2013, speaker en 2014, je suis venu en simple participant à l'édition 2015 dont le thème était : « le bonheur au travail » ! Bravo à toute l'équipe pour continuer ce travail bénévolement et garder cette conférence gratuite !

équipe agile tour 2015

Réflexion autour du travail et de son utilité (ou pas)

La keynote d'ouverture par Lionel Dricot @ploum lance le ton de la journée ! Une réflexion argumentée sur la fin du travail à lire en détails sur son blog.

Cette conférence porte un message clairement politique, et d'ailleurs la première question fût sur le revenu de base qui paraît être une des mises en oeuvre possible de cette fin du travail. Pour moi cette Keynote tranche avec celle des précédentes éditions plus portées sur des pratiques agiles, et aurait plus sa place dans une conférence type TEDx. Un choix risqué mais assumé par l'équipe de cet agile tour !

résumé

Mob mob mob programming

J'ai poursuivi la journée avec la conférence proposée par Emmanuel Gaillot @egaillot et Jonathan Perret @jonathanperret de la coopérative /ut7, également les co-créateurs du coding goûter. Un atelier live très sympa sur un serveur minecraft customisé à l'aide du CanaryMod et de ScriptsCraft voir ici pour les détails, dans la continuité de leurs activités de présentation du code aux enfants. Concernant le thème de cet agile tour : Oui on peut s'amuser en codant :). J'aurais aimé plus de discussions autour de leurs expériences « d'enseignant/coach/guru » auprès des enfants.

Lighting talks

LT : les feedbacks loops

Le premier de @rhwy Rui Carvalho sur les feedback loops, avec une image très sympa qui montre bien les boucles de contrôles (de la gestion de projet) et les boucles d'amplifications (de la qualité du code). Un autre moyen détourné de dire : l'agilité, oui, mais si vous ne faîtes rien sur ces boucles d'amplifications... vous aurez toujours une piètre qualité.

Sur ces boucles de feedback

LT : le courage de vivre consciemment

Le second talk de Jérôme Avoustin @JeromeAvoustin est un retour d'expérience sur sa carrière professionelle. Un appel aux développeurs malheureux en ESN (ex-SSII) et autres grosses boites, à aller de l'avant et à prendre des risques. Chez Yaal, ce pas là on l'a déjà fait, on est un collectif d'hommes et de femmes libres. :)

LT : la recette pour développer son logiciel dans le bonheur

Le dernier talk de Guillaume St-Etienne @guillaume_agile était vraiment lent, mais je suppose que la répétition était volontaire. En résumé, Guillaume souhaite un ou des outils magiques pour avoir un logiciel de qualité, rapide, qui s'autogère, assure les besoins clients, les anticipe, met la doc à jour tout seul, s'assure d'être à la pointe de la technologie... et fait le café !

Conclusion, cet outil magique existe : c'est un développeur ! Ce qui ne colle pas à cette fin du travail de @ploum :(

Chez Yaal, on a envie de compléter : c'est une équipe de développement, parce que le design d'interface des développeurs c'est pas encore ça :)

Ca prendra combien de temps ?

Après une pause déjeuner au soleil ! Je suis allé voir comme beaucoup d'autres la conférence d'Olivier Azeau @oaz. J'avoue avoir été pas mal déçu par cette présentation. Avec le recul je pense que c'est dû à cette volonté d'avoir un truc fiable pour estimer les développement.

C'est d'ailleurs l'idée expérimentée par Olivier : modéliser ces story points / tailles de T-shirt sous forme mathématique à l'aide de la théorie des probabilités section variable aléatoire. Olivier l'a bien annoncé : il n'est pas mathématicien, et du coup n'a pas pu vraiment répondre aux questions techniques. Je pense que c'est un premier retour d'expérience qui cherche à éliminer quelque part l'estimation d'experts au doigt mouillé. C'est dans l'optique du mouvement #NoEstimates dont vous pouvez lire quelques articles qui cherche à se débarasser de ce besoin d'évaluer à l'avance les développements.

Je ne suis pas convaincu du résultat, car au vu des graphes présentés, le constat amer est qu'entre l'estimation basse et l'estimation haute, on reste toujours sur un facteur 10, à 80% de probabilité. Même si une garantie mathématique se trouve derrière, je reste en tant que potentiel client d'une telle solution bien trop insatisfait. Le doigt mouillé du capitaine avec 30 ans de voile me paraît plus sûr que l'indice météo calculé, même si le résultat sur le long terme est le même. Cela reste une question de confiance dans le modèle. L'avantage que j'y vois est qu'on ne passe plus de temps à évaluer (NoEstimate), à la place on fournit le résulat d'un modèle mathématique.

Beaucoup de recherches ont été menées sur le sujet sans avoir de solution satisfaisante côté utilisateur.

Bref un sujet qui n'a pas encore trouvé de solution, mais en existe-t-il une ? Est-ce vraiment un problème ? (Pour faire des devis, oui !)

L'agilité en IUT

Enfin j'ai profité du retour d'expérience de Martine Bornerie @Martine__B et Irène Doan @idetido sur « l'agilité en IUT ».

Il est très intéressant de constater que cela fait tout juste un an que les projets en mode agile sont plus nombreux dans cet IUT MMI Bordeaux que ceux en cycle en V. Le début de la fin d'une époque ?

La recherche du bonheur

Enfin, on termine par la keynote de clôture d'Alexis Monville @alexismonville sur « la recherche du bonheur ». Les slides sont disponibles par ici. Le constat scientifique est formel : les gens heureux vivent mieux, plus longtemps, travaillent plus efficacement et bien d'autres qualités ! Bonus : ils aident les autres à mieux travailler en équipe !

Et Après ?

Pour d'autres retours, direction les blogs de :

[AFPy-Nantes] Un petit barcamp en novembre 2015 ?!

Publié le 2015-11-16 23:00:00

La prochaine rencontre Python Nantes sera au format BarCamp et se déroulera le jeudi 26 novembre de 19h à 21h, à la Cantine de Nantes.

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

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

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

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

À bientôt !