blog entries created by Sylvain Thenault
back to pagination (10 results)
  • Le forum ouvert

    2016/11/23 by Sylvain Thenault

    J'ai eu l'occasion de participer une nouvelle fois à un forum ouvert lors de la rencontre autour de l'entreprise libérée organisée par l'APAP et NOÏO (la dernière, c'était à l'Agile Tour Toulouse) . J'en ai fait un petit compte-rendu mais ce n'est pas l'objet de ce billet.

    Comme je trouve que le forum ouvert est vraiment un format super pour tirer le meilleur parti d'un groupe de gens indépendamment de la taille du groupe, je vais ici faire un petit rappel des bases (telles qu'elles nous ont été rappellées lors de cette rencontre), qu'on peut ensuite adapter en fonction de ses propres contraintes.

    Les principes du forum ouvert (ou Open Space) sont inspirés du fait que dans les conférences, la plupart des choses intéressantes sont dites en off : en discutant entre les conférences, pendant le café, devant la porte, etc. L'idée est donc de transformer la conférence en une grande pause avec des discussions libres, en petit groupe, autour d'un thème donné et avec les quatre principes suivants pour mettre tout le monde à l'aise :

    • toutes les personnes présentes sont les bonnes personnes,
    • ce qui arrive est ce qui pouvait arriver,
    • quelque soit le moment où ça commence, c'est le bon moment,
    • et quand c'est fini, c'est fini.
    https://www.logilab.org/file/9306538/raw/20161121_194647.jpg

    Partant de ces bases, un forum ouvert se déroule en quatre phases :

    1. introduction du sujet et des principes du forum ouvert énoncés ici,
    2. proposition et éventuellement sélection des sujets,
    3. plusieurs rounds de discussions sur les sujets choisis,
    4. choix d'actions et clôture.

    Une fois le sujet introduit, voici le détail du déroulement des étapes suivantes...

    L'émergence des sujets

    Dans cette première phase, chacun est invité à proposer un sujet qu'il va écrire en gros sur une feuille en y indiquant également son nom. Cette feuille sera affichée sur un tableau qu'on nomme la place du marché, accompagnée d'une indication de l'heure et du lieu où aura lieu cette discussion.

    Pour cette indication, l'organisateur aura au préalable préparé une grille d'emploi du temps déduite :

    • du nombre de discussions en parallèle (en fonction de l'espace ou des tables disponibles ainsi que du nombre de personnes présentes - compter entre 5 et 10 personnes max par groupe),
    • de la durée et le nombre de créneaux successifs (au moins 40 minutes pour un créneau, le temps passe vite !).

    À partir de ces informations on obtient une grille horaire dans laquelle les propositions pourront être placées, ainsi accompagnée d'un lieu (en général un numéro de table) et d'un créneau horaire.

    https://www.logilab.org/file/9306522/raw/20161121_194729.jpg

    On peut apparemment tabler sur une proposition de sujet pour deux personnes en moyenne. Si plusieurs propositions sont similaires, il est possible de les recouper si les porteurs du sujet le souhaitent. Enfin s'il est nécessaire de faire une sélection, on peut demander aux participants de "s'inscrire" sur les sujets afin de voir lesquels sont les moins suivis.

    Le temps des discussions

    Et c'est parti pour le premier round de discussion ! Chaque porteur de sujet s'installe à sa table, y indique clairement le sujet discuté (on laisse l'affichage général en place pour les retardataires et promeneurs) et attend d'être rejoint par d'autres personnes également intéressées par ce sujet. Il a deux responsabilités :

    • introduire le sujet,
    • s'assurer qu'un compte-rendu sera écrit (mais pas forcément par lui).

    Animer la discussion n'en fait pas parti.

    Pendant les discussions, on peut ajouter :

    • la loi des deux pieds : chacun est libre s'il en ressent l'envie pour une raison ou pour une autre de quitter sa table pour aller s'installer sur une autre,
    • les abeilles qui butinent de tables en tables, sans jamais vraiment s'installer mais en permettant d'essaimer l'information d'une table à l'autre,
    • les papillons qui papillonnent un peu en marge du processus, mais il n'est pas rare d'en voir émerger des choses.
    https://www.logilab.org/file/9306530/raw/20161121_194658.jpg

    Une dizaine de minutes avant la fin du créneau, l'organisateur indique qu'il est temps de s'assurer que le compte-rendu de la discussion sera fait. Enfin à la fin du temps imparti, chaque table va afficher son compte-rendu sur le grand journal.

    https://www.logilab.org/file/9306515/raw/20161121_212456.jpg

    Je trouve qu'il est intéressant de réserver un créneau à ce moment là pour qu'une personne par table présente ce compte-rendu en quelques minutes, car il est parfois difficile de se contenter de ce qui est écrit ou dessiné.

    Après on enchaîne rapidement sur le round suivant, et ainsi de suite.

    La clôture

    À ce moment là, tout le monde commence à être bien détendu, en confiance, et à connaître au moins une partie des participants. Afin de faire avancer la cause discutée, on va effectuer une dernier round de propositions / discussions dont l'objectif est de dégager des actions réalistes à court terme. Sur le modèle des étapes précédente, les participants sont invités à proposer une action qu'ils ont envie de tirer (ou de voir tirer) avec d'autres. Ils l'énoncent et l'affichent sur le marché aux actions.

    Une fois toutes les actions proposées, les personnes intéressées par une action donnée se regroupent et structurent une action qui sera énoncée devant l'assistance une fois le temps imparti écoulé. Si possible, l'organisateur effectuera un suivi de ces actions après l'évènement.

    https://www.logilab.org/file/9306297/raw/20161121_214833.jpg

    Il est ensuite temps de se féliciter, de se remercier, d'annoncer la suite ou toute autre chose utile avant de se quitter.

    Les photos sont tirées de l'évènement sus-cité, merci aux organisateurs et en particulier ici aux facilitateurs graphiques !


  • Rencontre autour de l'entreprise libérée à Toulouse

    2016/11/23 by Sylvain Thenault

    J'ai eu l'occasion de participer à une rencontre autour de l'entreprise libérée organisée par l'APAP et NOÏO sur Toulouse. Voici quelques notes pour la postérité.

    https://www.logilab.org/file/9306297/raw/20161121_214833.jpg

    La première partie de cette rencontre était la diffusion du documentaire E 3.0, Une entreprise humaniste qui présente les 6 premiers mois de la "libération" d'Averia, une entreprise de miroiterie d'ile de france. Le réalisateur était présent et nous a annoncé en amont de la projection son parti pris volontaire pour l'entreprise libérée (ce qui n'est pas pour me déplaire). J'ai trouvé ce documentaire intéressant de par l'aspect "témoignage sur le vif" et par le suivi sur quelques mois de cette phase critique de transformation. Ça donne envie de savoir où il en sont maintenant (la période filmée est le second semestre 2015).

    La seconde partie s'est déroulée sous la forme d'un forum ouvert. Au delà des sujets de départ que j'avais choisi, cela m'a surtout permis d'échanger avec d'autres personnes dont l'entreprise est plus ou moins avancée sur le chemin de la libération (j'ai du mal avec ce terme que je trouve un peu galvaudé mais bon). J'y ai notamment rencontré une dirigeante d'une société de pose de parquets (Erah), en voie de "libération" depuis 5 ans. Celle-ci a pour le moins étonné tout le monde lorsqu'elle nous a appris que ses salariés avaient décidés ensemble d'être tous payés pareils, indépendamment de leur expérience (mais légèrement au dessus des prix du marché même pour les expérimentés), ou encore que la société finançait à ses salariés des stages sur leur temps de travail, indépendamment de l'intérêt du sujet pour elle. J'ai également discuté avec la dirigeante de Fun and fly qui gère son entreprise d'une dizaine de personnes dans la veine de l'entreprise libérée sans le savoir jusqu'ici. Non sans similitude avec Logilab, où nous avons grandi depuis 2000 avec bon nombre de principes aujourd'hui regroupés sous la bannière de l'entreprise libérée.

    https://www.logilab.org/file/9306355/raw/20161121_222142.jpg

    La soirée s'est conclut pour moi avec le directeur de Web-Atrio qui devrait prochainement inviter le petit groupe que nous avons formé à un déjeuner ou diner afin d'aller plus loin dans les échanges autour de nos avancées et expérimentations respectives, élément qui est apparu essentiel à chacun, même si nous n'espérons pas y trouver de recettes miracles s'appliquant à tout le monde.

    Pour aller plus loin, le lecteur intéressé pourra :

    • regarder cette conférence d'Isaac Getz qui m'a été recommandée pendant la soirée (à Logilab Toulouse nous en avons regardé une de Frédéric Laloux que je recommende également si vous n'avez pas lu son livre),
    • lire une bande dessinée à ce sujet,
    • suivre ce qu'il se passe du côté de l'association MOM21, qui devrait notamment créer une antenne Sud-Ouest et organiser une journée à ce sujet le 18 janvier prochain (mais je n'ai pas trouvé plus d'info à ce sujet sur leur site).

    Merci à tous les organisateurs pour ce moment rondement mené et qui a permis de se rendre compte qu'on n'est pas seul sur le chemin !


  • Mon premier Agile Games

    2016/03/15 by Sylvain Thenault

    Vendredi et samedi dernier j'ai participé à la 6ème édition de la non-conférence Agile Games France. J'étais assez privilégié sur ce coup-là puisqu'en plus de faire partie des heureux possesseurs d'une entrée, l'événement se déroulait dans mon village, Nailloux ! Voici un petit compte-rendu de ces deux jours.

    Pour commencer il faut savoir que Agile Games est une "non-conférence" : tout est auto-organisé, depuis le choix du lieu jusqu'à la sélection du programme en live. Comme dit Alex, "c'est un peu comme un forum ouvert, mais en moins organisé" ! Chacun affiche sur un mur les jeux qu'il se propose d'animer, voire ceux auxquels il voudrait jouer dans l'espoir que quelqu'un se propose. Ensuite c'est parti ! Et ça marche, moyennant qu'il ne faut pas rater le coche lorsqu'un jeu qui vous intéresse démarre.

    https://www.logilab.org/4980434?vid=download

    Le journée du vendredi a commencé pour moi par le cube bleu. L'objectif est de montrer notre rapport à l'engagement : comme chacun fonctionne différemment face à un engagement, ou encore la différence entre prendre un engagement individuel par rapport à un engagement collectif. Excellent rapport ludicité / apprentissage de mon point de vue.

    J'ai ensuite pas mal papilloné sans vraiment m'installer nulle part : crayon d'Ariane, Néo le robot agile, Playing lean ou encore le Bikascrum... Il y a de l'activité partout et même ainsi on ne s'ennuie pas. J'ai fini par m'installer en début d'après-midi dans un atelier aidant à comprendre et appliquer les principes de la communication non-violente. L'exercice est difficile mais intéressant (j'avoue être impressionné par la maitrise d'Isabel). Enfin, la journée s'est achevée par une petite dégustation de vin : "In vino veritas", animé par l'équipe nantaise d'Agile Garden. On y a approché la différence entre les résultats obtenus de manière individuelle ou en groupe, sans modération particulière. Comme souvent, la vérité est dans un compromis, ou du moins dans une approche permettant à chacun de s'exprimer.

    Le samedi j'ai attaqué par un icebreaker créatif : commencer par dessiner son voisin, histoire de mettre chacun à l'aise, avant de faire par équipe une mind-map libre, que l'autre équipe devra deviner en partant des feuilles. Et pour encore plus d'énergie, un bon temps dehors pour un chifoumi collectif déjanté, avant de faire un parallèle entre le théatre d'improvisation et les valeurs de l'agilité.

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

    L'après-midi, ce fut un energizer collectif "Zoom" autour de l'auto-organisation, planète derdian sur le thème de l'interculturalité, ball point game pour illustrer les interactions équipe / client dans un cadre agile, ou encore un début de jeu expérimental d'Alex où l'on met en place une chorégraphie pour illustrer la conduite du changement.

    Voilà. Et je ne vous parle pas des rencontres, des moments de discussion ou encore du tas d'autres jeux auxquels je n'ai pas participé (improvement kata, beer game, pompafric et autres jeux de cartes et de plateaux)... Bref, un moment plein d'énergie dont on repart ressourcé et inspiré. C'était mon premier Agile Games, et j'espère bien en faire plein d'autres !

    Si vous voulez en savoir plus ou trouver des liens sur les jeux cités, vous pouvez aller voir les billets de Chris ou encore celui de Fabrice.

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

    (photo by B.Cabanne)

    Merci à tous les non-organisateurs et participants, et en particulier à Claude pour m'avoir aiguillé jusque là.


  • Tisséo, bon élève de l'Open Data

    2015/11/12 by Sylvain Thenault

    J'ai assisté mardi dernier à un "6 à 8" à la Cantine de Toulouse, sur le thème de l'Open-Data chez Tisséo, opérateur des transports en commun du coin.

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

    (photo par Cc By SA Guillaume Paumier licence CC-By-SA)

    Sandrine Mathon, pour le compte de Toulouse Métropole, nous a présenté Cyril Boitel, responsable données "statiques" et Xavier Raffin, responsable de l'infrastructure et de l'API pour l'accès au données "temps réels". Cyril et Xavier nous ont fait une rapide présentation avant de passer à l'essence de ce type d'évènement : le buffet ! Hormis les petits fours, voici quelques points que j'ai retenu...

    Tisséo est associé à la démarche d'ouverture des données à Toulouse depuis l'origine ou presque, soit depuis 4 ans. Elle publie aujourd'hui une API d'accès aux données temps réel, deux fichiers horaires statiques (GTFS, NEPTUNE/ Trident), 3 fichiers cartographiques (métro, tram, bus), et répond à environ 8 millions de requêtes par mois. Les données sont sous licences ODBL.

    L'accès à l'API est conditionné par l'obtention d'une clé, sur simple demande. Non pas pour juger de votre projet et encore moins de qui la demande, mais simplement pour établir un contact avec l'équipe et permettre ensuite à Tisséo de faire quelques statistiques. Et cela permet au pire de bloquer l'accès à une clé en cas d'usage abusif de l'API, mais ils ont plus souvent affaire à des accidents que des vraies tentatives d'attaque de type DOS. Dans ces cas là, l'équipe prend contact pour signaler le problème avant de recourir au blocage de la clé. Depuis l'ouverture du service, un peu plus de 200 clés ont été délivrées (attention, certaines sont utilisées par des promos entières d'étudiants !).

    Leurs statistiques, outre un volume en progression constante, montrent que l'essentiel des requêtes est généré par les systèmes de complétion, qui génèrent une nouvelle requête dès qu'un petit caractère change. Les trucs plus compliqués comme le calcul d'itinéraire ne représentent que quelques pourcents du total. J'ai d'ailleurs appris à ce sujet l'existence (j'avoue ne m'être jamais posé la question) de plusieurs calculateurs d'itinéraire Open-Source : navitia.io, OpenTripPlanner ou encore SYNTHESE. Apparemment chez Tisséo ils ont un peu goûté à tout, mais ils sont en train de migrer vers navitia.io, qui possède quelques belles références.

    Je finirais par les deux points qui me font penser au côté "bon élève" de l'Open-Data : d'abord cette démarche, qui n'a pas fait que des heureux en interne et représente un coût, a permis d'une part une amélioration de la qualité des données qu'ils avaient eux même à disposition, et d'autre part une rationalisation de l'infrastructure, car leur application mobile est branchée sur la même API que celle mise à disposition du public. En prime, ce dernier point motive évidemment à avoir tout en ordre de marche et aide à trouver les bugs avant les autres. Tous les avantages du eat your own dog food quoi ! Enfin, Tisséo est engagé dans un groupe de réflexion autour de l'Open-Transport qui inclut, entre autres poids lourds du secteur, la SNCF afin de tenter de normaliser un peu tout ça.

    Ces deux points sont de mon point de vue deux facteurs clés de l'Open-data et ne sont pas encore mis assez en avant. Ça aura donc été une occasion de l'entendre et de le redire, merci à Sandrine, Cyril et Xavier !


  • Méthodes Agiles et logiciels sûrs

    2015/09/23 by Sylvain Thenault

    J'ai assisté ce mercredi à une journée d'étude sur le thème "agilité et logiciels sûrs". Organisé par Aerospace Valley, il y avait une quarantaine de personnes, à la fois des agilistes expérimentés et des curieux, voir dubitatifs, pour l'essentiel venant des industriels du secteur.

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

    C'est Claude Aubry qui s'est chargé de chauffer la salle en posant les fondements de l'agilité en général et de Scrum en particulier. Je ne vais pas m'étendre sur cette présentation rapide, efficace et appréciée, si ce n'est sur les rappels suivants qui me paraissent particulièrement intéressants dans le contexte :

    • l'agilité est une culture avant d'être des processus,
    • cela permet de gérer le décalage entre les plans et la réalité grâce à une boucle de rétroaction courte,
    • c'est fait pour gérer des systèmes complexes et adaptatifs,
    • dans le cadre du développement de logiciel sûr, on prendra notamment soin à :
      • la présence d'experts lors des réunions d'affinage,
      • la définition de fini,
      • montrer l'incertitude.

    Je citerai pour conclure cette introduction la définition de l'Agilité selon Claude :

    "l'agilité est la capacité d'une organisation à fournir tôt et souvent de la valeur, tout en s'adaptant à temps aux changements dans son environnement"
    https://upload.wikimedia.org/wikipedia/commons/1/1a/ST_vs_Gloucester_-_Match_-_23.JPG

    (photo par Pierre Selim, licence CC-By-SA 3.0)

    Gérard Ladier et Jean-Paul Blanquart sont ensuite entrés dans le vif du sujet avec une double-présentation-avec-passe-de-ballon (oui oui, y avait 2 projections simultanées avec 2 projecteurs) sur le sujet des contraintes liées au besoin de certification dans le cadre de l'aéronautique pour Gérard et du spatial pour Jean-Paul.

    En commençant par rappeler que normes et règlements ne sont pas là (que) pour nous embêter mais avant tout pour protéger des parties prenantes qui n'ont pas forcément leur mot à dire dans le cadre de la définition d'un produit. Comme vous et moi dans le cadre d'un nouvel avion par exemple : on nous demande pas notre avis mais on pourrait bien finir par le prendre. Ainsi, ces normes et règlements sont censés fournir un cadre permettant de répondre à un objectif de très haut niveau, aussi simple que "on ne doit pas risquer sa vie en montant dans un avion de ligne".

    Je vais passer sur la plupart des points techniques, si ce n'est pour citer la fameuse DO-178C aéronautique qui est la norme définissant les différents niveaux de conformité qu'un logiciel devra agréer dans le cadre de la certification d'un programme. Apparemment, s'il y en a bien une à connaître c'est celle-ci (et ECSS côté spatial).

    Le point important, c'est que ces normes découpent le projet en phase avec des échéances obligatoires mais sans pour autant y associer de méthode. Notamment le cycle de développement en soi n'est pas normé. Il n'y a donc pas de contre-indications à utiliser des méthodes agiles pour répondre aux exigences de ces normes. Ce qui ne veut pas dire qu'il n'y a pas de résistance au changement des habitudes, et notamment celles des experts...

    Gérard a complété ce numéro de duettistes par une présentation des attentes d'Airbus en manière d'agilité :

    1. changer la manière de développer pour accompagner le passage à un mode de développement incrémental des avions et obtenir une diminution du time-to-market,
    2. diminuer les coûts liés aux défauts pour permettre l'augmentation des taux de productions,
    3. améliorer la gestion du risque et de la complexité afin de faire face à l'augmentation des coût de développement

    Donc si on en croit cette présentation, Airbus constate qu'il faut apprendre à travailler différemment, ils sont prêts à tester l'agilité sur des sous-systèmes (trop disruptif sur un système complet, faut pas pousser !) et sont même en attente de challenges de la part de leur partenaires. À suivre !

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

    (photo par pixabay, licence CC0)

    L'après-midi, on est reparti sur les chapeaux de roue avec une présentation d'Emmanuel Chenu de Thales Avionics, porteur d'un message massue : "on l'a fait (et on en est content)". Tout part du constat des problèmes liés à l'intégration "big-bang" entre logiciels ou entre logiciel et matériel, mais aussi du fait que mener les activités liées à la certification tardivement et en gros lots :

    • ne réduit pas la complexité,
    • ne permet pas de corriger tôt les pratiques,
    • génère des activités peu efficaces et pas fiables,
    • empire avec l'avancée dans le projet.

    Ces choix ne sont évidemment pas un hasard, ils s'expliquent en particulier par le besoin de versions anticipées non certifiées, ou encore par les échéances des audits qui collent au cycle en V. Malgré tout cela, ils ont donc tenté d'appliquer l'agilité aux développements d'une centrale inertielle pour l'A350 (ADIRU de son petit nom). Ce projet, qui doit répondre au plus haut niveau de la norme DO-178C, est spécifié par plusieurs milliers d'exigences et est constitué au final de plus de 500 000 lignes de code spécifiques. Et il semblerait qu'à l'issue du projet, tout le monde était content :

    • l'avionneur, car il a eu plusieurs livraisons intermédiaires sans régressions et avec globalement moins de défauts (environ 0.15 / kLOC, soit un facteur 100 par rapport aux taux habituels d'après Emmanuel),
    • le service qualité, car il a des retours rapides, globalement moins de soucis et qu'il apprécie la motivation de l'équipe, à la fois à développer et à améliorer son process,
    • l'autorité de certification, qui a été impressionné par le respect des exigences du produit.

    Et vu le deuxième point, on peut raisonnablement penser que l'équipe Thales était contente aussi !

    Les enseignements tirés par Thales et identifiés comme des savoir-faire critiques sont :

    • "produit potentiellement livrable" = le logiciel accompagné de tous les artefacts qui vont avec (notamment ceux nécessaires pour la certification des features développées),
    • l'importance en premier lieu des pratiques techniques:
      • architecture objet
      • test de couverture automatisés
      • intégration continue
      • safe delivery
      • stop the line
      • design by contract
      • qualimétrie
    • il est indispensable d'avoir une gestion de configuration très rigoureuse, notamment en utilisant du versionnement pour les exigences comme pour le code,
    • il faut réorganiser les revues pour ne pas coller au cycle en V, et décrire les itérations et incréments dans les plans.

    Évidemment, comme toujours en développement agile mais encore plus ici : la qualité n'est pas une variable d'ajustement. Et le processus dans son ensemble est suivi par un certain nombre d'indicateurs dont :

    • une mesure "qualité" sur le long terme (somme de critères évolutifs),
    • la couverture des tests,
    • le nombre d'exigences satisfaites.

    Au final, l'avionneur peut s'appuyer sur les versions intermédiaires pour développer d'autres parties de manière incrémentale, il a une mesure plus objective de l'avancement et il obtient une baisse significative des défauts résiduels et de l'impact des changements de priorité. Surtout, Thales démontre ici que l'agilité et la certification DO-178C ne sont pas incompatibles, bien au contraire.

    https://upload.wikimedia.org/wikipedia/commons/thumb/8/8c/Airbus_A350-900_XWB_Airbus_Industries_%28AIB%29_MSN_001_-_F-WXWB_%2810223175703%29.jpg/640px-Airbus_A350-900_XWB_Airbus_Industries_%28AIB%29_MSN_001_-_F-WXWB_%2810223175703%29.jpg

    (photo par Laurent Errera, licence CC-By-SA 2.0)

    La dernière présentation de l'après-midi était celle de Vincent Meunier (SII), mais je dois avouer que mon attention était déjà sévèrement entamée et que le fait qu'il y ait pas mal de recouvrement avec les présentations précédentes l'a achevée. Je me contenterai donc des points suivants que j'ai relevés :

    • il faut coopérer avec tout le monde, y compris les autorités,
    • ne surtout pas retarder les éléments risqués,
    • tester dans un sprint les processus ou les outils dont on doute,
    • adapter le processus global,
    • laisser l'équipe suggérer les améliorations.

    L'après-midi s'est terminée par une séance de brainstorming autour des points à améliorer ou des actions à mener afin d'étendre l'usage de l'agilité dans le contexte de logiciels sûrs. De nombreuses idées ont été soulevés par l'ensemble de l'audience, visiblement intéressée par le sujet. Au point que le pôle Aerospace Valley semble prêt à creuser encore le sujet via un groupe de discussion.

    J'ai de mon côté été agréablement surpris de ce que j'ai vu et entendu. Arrivant avec un a priori négatif sur la relation du milieu l'aéronautique (et en particulier d'Airbus) vis-à-vis de l'agilité, cette journée me fait penser que c'est possible, au moins localement ! Quant au temps qu'il faudra pour faire bouger les lignes, l'avenir nous le dira - mais ça va être long.

    En tout cas merci à Aerospace Valley et en particulier à Gérard Ladier pour cette journée, ainsi qu'à l'ensemble des intervenants qui étaient tous de grande qualité.


  • Exemple de "contrat agile" mis en place entre Logilab et ses clients

    2015/06/18 by Sylvain Thenault

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

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

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

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

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

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

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

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

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


  • De retour du raid agile

    2015/03/17 by Sylvain Thenault
    https://www.logilab.org/file/288474?vid=download

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

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

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

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

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

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

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

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


  • Pylint 1.3 / Astroid 1.2 released

    2014/07/28 by Sylvain Thenault

    The EP14 Pylint sprint team (more on this here and there) is proud to announce they just released Pylint 1.3 together with its companion Astroid 1.2. As usual, this includes several new features as well and bug fixes. You'll find below some structured list of the changes.

    Packages are uploaded to pypi, debian/ubuntu packages should be soon provided by Logilab, until they get into the standard packaging system of your favorite distribution.

    Please notice Pylint 1.3 will be the last release branch support python 2.5 and 2.6. Starting from 1.4, we will only support python greater or equal to 2.7. This will be the occasion to do some great cleanup in the code base. Notice this is only about the Pylint's runtime, you should still be able to run Pylint on your Python 2.5 code, through using Python 2.7 at least.

    New checks

    • Add multiple checks for PEP 3101 advanced string formatting: 'bad-format-string', 'missing-format-argument-key', 'unused-format-string-argument', 'format-combined-specification', 'missing-format-attribute' and 'invalid-format-index'
    • New 'invalid-slice-index' and 'invalid-sequence-index' for invalid sequence and slice indices
    • New 'assigning-non-slot' warning, which detects assignments to attributes not defined in slots

    Improved checkers

    • Fixed 'fixme' false positive (#149)
    • Fixed 'unbalanced-iterable-unpacking' false positive when encountering starred nodes (#273)
    • Fixed 'bad-format-character' false positive when encountering the 'a' format on Python 3
    • Fixed 'unused-variable' false positive when the variable is assigned through an import (#196)
    • Fixed 'unused-variable' false positive when assigning to a nonlocal (#275)
    • Fixed 'pointless-string-statement' false positive for attribute docstrings (#193)
    • Emit 'undefined-variable' when using the Python 3 metaclass= argument. Also fix 'unused-import' false for that construction (#143)
    • Emit 'broad-except' and 'bare-except' even if the number of except handlers is different than 1. Fixes issue (#113)
    • Emit 'attribute-defined-outside-init' for all statements in the same module as the offended class, not just for the last assignment (#262, as well as a long standing output mangling problem in some edge cases)
    • Emit 'not-callable' when calling properties (#268)
    • Don't let ImportError propagate from the imports checker, leading to crash in some namespace package related cases (#203)
    • Don't emit 'no-name-in-module' for ignored modules (#223)
    • Don't emit 'unnecessary-lambda' if the body of the lambda call contains call chaining (#243)
    • Definition order is considered for classes, function arguments and annotations (#257)
    • Only emit 'attribute-defined-outside-init' for definition within the same module as the offended class, avoiding to mangle the output in some cases
    • Don't emit 'hidden-method' message when the attribute has been monkey-patched, you're on your own when you do that.

    Others changes

    • Checkers are now properly ordered to respect priority(#229)
    • Use the proper mode for pickle when opening and writing the stats file (#148)

    Astroid changes

    • Function nodes can detect decorator call chain and see if they are decorated with builtin descriptors (classmethod and staticmethod).
    • infer_call_result called on a subtype of the builtin type will now return a new Class rather than an Instance.
    • Class.metaclass() now handles module-level __metaclass__ declaration on python 2, and no longer looks at the __metaclass__ class attribute on python 3.
    • Add slots method to Class nodes, for retrieving the list of valid slots it defines.
    • Expose function annotation to astroid: Arguments node exposes 'varargannotation', 'kwargannotation' and 'annotations' attributes, while Function node has the 'returns' attribute.
    • Backported most of the logilab.common.modutils module there, as most things there are for pylint/astroid only and we want to be able to fix them without requiring a new logilab.common release
    • Fix names grabed using wildcard import in "absolute import mode" (i.e. with absolute_import activated from the __future__ or with python 3) (pylint issue #58)
    • Add support in brain for understanding enum classes.

  • EP14 Pylint sprint Day 2 and 3 reports

    2014/07/28 by Sylvain Thenault
    https://ep2014.europython.eu/static_media/assets/images/logo.png

    Here are the list of things we managed to achieve during those last two days at EuroPython.

    After several attempts, Michal managed to have pylint running analysis on several files in parallel. This is still in a pull request (https://bitbucket.org/logilab/pylint/pull-request/82/added-support-for-checking-files-in) because of some limitations, so we decided it won't be part of the 1.3 release.

    Claudiu killed maybe 10 bugs or so and did some heavy issues cleanup in the trackers. He also demonstrated some experimental support of python 3 style annotation to drive a better inference. Pretty exciting! Torsten also killed several bugs, restored python 2.5 compat (though that will need a logilab-common release as well), introduced a new functional test framework that will replace the old one once all the existing tests will be backported. On wednesday, he did show us a near future feature they already have at Google: some kind of confidence level associated to messages so that you can filter out based on that. Sylvain fixed a couple of bugs (including https://bitbucket.org/logilab/pylint/issue/58/ which was annoying all the numpy community), started some refactoring of the PyLinter class so it does a little bit fewer things (still way too many though) and attempted to improve the pylint note on both pylint and astroid, which went down recently "thanks" to the new checks like 'bad-continuation'.

    Also, we merged the pylint-brain project into astroid to simplify things, so you should now submit your brain plugins directly to the astroid project. Hopefuly you'll be redirected there on attempt to use the old (removed) pylint-brain project on bitbucket.

    And, the good news is that now both Torsten and Claudiu have new powers: they should be able to do some releases of pylint and astroid. To celebrate that and the end of the sprint, we published Pylint 1.3 together with Astroid 1.2. More on this here.


  • EP14 Pylint sprint Day 1 report

    2014/07/24 by Sylvain Thenault
    https://ep2014.europython.eu/static_media/assets/images/logo.png

    We've had a fairly enjoyable and productive first day in our little hidden room at EuroPython in Berlin ! Below are some noticeable things we've worked on and discussed about.

    First, we discussed and agreed that while we should at some point cut the cord to the logilab.common package, it will take some time notably because of the usage logilab.common.configuration which would be somewhat costly to replace (and is working pretty well). There are some small steps we should do but basically we should mostly get back some pylint/astroid specific things from logilab.common to astroid or pylint. This should be partly done during the sprint, and remaining work will go to tickets in the tracker.

    We also discussed about release management. The point is that we should release more often, so every pylint maintainers should be able to do that easily. Sylvain will write some document about the release procedure and ensure access are granted to the pylint and astroid projects on pypi. We shall release pylint 1.3 / astroid 1.2 soon, and those releases branches will be the last one supporting python < 2.7.

    During this first day, we also had the opportunity to meet Carl Crowder, the guy behind http://landscape.io, as well as David Halter which is building the Jedi completion library (https://github.com/davidhalter/jedi). Landscape.io runs pylint on thousands of projects, and it would be nice if we could test beta release on some part of this panel. On the other hand, there are probably many code to share with the Jedi library like the parser and ast generation, as well as a static inference engine. That deserves a sprint on his own though, so we agreed that a nice first step would be to build a common library for import resolution without relying on the python interpreter for that, while handling most of the python dark import features like zip/egg import, .pth files and so one. Indeed that may be two nice future collaborations!

    Last but not least, we got some actual work done:

    • Michal Nowikowski from Intel in Poland joined us to work on the ability to run pylint in different processes so it may drastically improve performance on multiple cores box.
    • Torsten did continue some work on various improvements of the functionnal test framework.
    • Sylvain did merge logilab.common.modutils module into astroid as it's mostly driven by astroid and pylint needs. Also fixed the annoying namespace package crash.
    • Claudiu keep up the good work he does daily at improving and fixing pylint :)

  • PyLint sprint during EuroPython in Berlin

    2014/07/11 by Sylvain Thenault

    The three main maintainers/developpers of Pylint/astroid (Claudiu, Torsten and I) will meet together in Berlin during EuroPython 2014. While this is not an "official" EuroPython sprint but it's still worth announcing it since it's a good opportunity to meet and enhance Pylint. We should find place and time to work on Pylint between wednesday 23 and friday 25.

    If you're interested, don't hesitate to contact me (sylvain.thenault@logilab.fr / @sythenault).


  • Pylint 1.2 released!

    2014/04/22 by Sylvain Thenault

    Once again, a lot of work has been achieved since the latest 1.1 release. Claudiu, who joined the maintainer team (Torsten and me) did a great work in the past few months. Also lately Torsten has backported a lot of things from their internal G[oogle]Pylint. Last but not least, various people contributed by reporting issues and proposing pull requests. So thanks to everybody!

    Notice Pylint 1.2 depends on astroid 1.1 which has been released at the same time. Currently, code is available on Pypi, and Debian/Ubuntu packages should be ready shortly on Logilab's acceptance repositories.

    Below is the changes summary, check the changelog for more info.

    New and improved checks:

    • New message 'eval-used' checking that the builtin function eval was used.
    • New message 'bad-reversed-sequence' checking that the reversed builtin receive a sequence (i.e. something that implements __getitem__ and __len__, without being a dict or a dict subclass) or an instance which implements __reversed__.
    • New message 'bad-exception-context' checking that raise ... from ... uses a proper exception context (None or an exception).
    • New message 'abstract-class-instantiated' warning when abstract classes created with abc module and with abstract methods are instantied.
    • New messages checking for proper class __slots__: 'invalid-slots-object' and 'invalid-slots'.
    • New message 'undefined-all-variable' if a package's __all__ variable contains a missing submodule (#126).
    • New option logging-modules giving the list of module names that can be checked for 'logging-not-lazy'.
    • New option include-naming-hint to show a naming hint for invalid name (#138).
    • Mark file as a bad function when using python2 (#8).
    • Add support for enforcing multiple, but consistent name styles for different name types inside a single module.
    • Warn about empty docstrings on overridden methods.
    • Inspect arguments given to constructor calls, and emit relevant warnings.
    • Extend the number of cases in which logging calls are detected (#182).
    • Enhance the check for 'used-before-assignment' to look for nonlocal uses.
    • Improve cyclic import detection in the case of packages.

    Bug fixes:

    • Do not warn about 'return-arg-in-generator' in Python 3.3+.
    • Do not warn about 'abstract-method' when the abstract method is implemented through assignment (#155).
    • Do not register most of the 'newstyle' checker warnings with python >= 3.
    • Fix 'unused-import' false positive with augment assignment (#78).
    • Fix 'access-member-before-definition' false negative with augment assign (#164).
    • Do not crash when looking for 'used-before-assignment' in context manager assignments (#128).
    • Do not attempt to analyze non python file, eg '.so' file (#122).
    • Pass the current python path to pylint process when invoked via epylint (#133).

    Command line:

    • Add -i / --include-ids and -s / --symbols back as completely ignored options (#180).
    • Ensure init-hooks is evaluated before other options, notably load-plugins (#166).

    Other:

    • Improve pragma handling to not detect 'pylint:*' strings in non-comments (#79).
    • Do not crash with UnknownMessage if an unknown message identifier/name appears in disable or enable in the configuration (#170).
    • Search for rc file in ~/.config/pylintrc if ~/.pylintrc doesn't exists (#121).
    • Python 2.5 support restored (#50 and #62).

    Astroid:

    • Python 3.4 support
    • Enhanced support for metaclass
    • Enhanced namedtuple support

    Nice easter egg, no?


  • Pylint 1.1 christmas release

    2013/12/24 by Sylvain Thenault

    Pylint 1.1 eventually got released on pypi!

    A lot of work has been achieved since the latest 1.0 release. Various people have contributed to add several new checks as well as various bug fixes and other enhancement.

    Here is the changes summary, check the changelog for more info.

    New checks:

    • 'deprecated-pragma', for use of deprecated pragma directives "pylint:disable-msg" or "pylint:enable-msg" (was previously emmited as a regular warn().
    • 'superfluous-parens' for unnecessary parentheses after certain keywords.
    • 'bad-context-manager' checking that '__exit__' special method accepts the right number of arguments.
    • 'raising-non-exception' / 'catching-non-exception' when raising/catching class non inheriting from BaseException
    • 'non-iterator-returned' for non-iterators returned by '__iter__'.
    • 'unpacking-non-sequence' for unpacking non-sequences in assignments and 'unbalanced-tuple-unpacking' when left-hand-side size doesn't match right-hand-side.

    Command line:

    • New option for the multi-statement warning to allow single-line if statements.
    • Allow to run pylint as a python module 'python -m pylint' (anatoly techtonik).
    • Various fixes to epylint

    Bug fixes:

    • Avoid false used-before-assignment for except handler defined identifier used on the same line (#111).
    • 'useless-else-on-loop' not emited if there is a break in the else clause of inner loop (#117).
    • Drop 'badly-implemented-container' which caused several problems in its current implementation.
    • Don't mark input as a bad function when using python3 (#110).
    • Use attribute regexp for properties in python3, as in python2
    • Fix false-positive 'trailing-whitespace' on Windows (#55)

    Other:

    • Replaced regexp based format checker by a more powerful (and nit-picky) parser, combining 'no-space-after-operator', 'no-space-after-comma' and 'no-space-before-operator' into a new warning 'bad-whitespace'.
    • Create the PYLINTHOME directory when needed, it might fail and lead to spurious warnings on import of pylint.config.
    • Fix setup.py so that pylint properly install on Windows when using python3.
    • Various documentation fixes and enhancements

    Packages will be available in Logilab's Debian and Ubuntu repository in the next few weeks.

    Happy christmas!


  • A quick take on continuous integration services for Bitbucket

    2013/12/19 by Sylvain Thenault

    Some time ago, we moved Pylint from this forge to Bitbucket (more on this here).

    https://bitbucket-assetroot.s3.amazonaws.com/c/photos/2012/Oct/11/master-logo-2562750429-5_avatar.png

    Since then, I somewhat continued to use the continuous integration (CI) service we provide on logilab.org to run tests on new commits, and to do the release job (publish a tarball on pypi, on our web site, build Debian and Ubuntu packages, etc.). This is fine, but not really handy since the logilab.org's CI service is not designed to be used for projects hosted elsewhere. Also I wanted to see what others have to offer, so I decided to find a public CI service to host Pylint and Astroid automatic tests at least.

    Here are the results of my first swing at it. If you have others suggestions, some configuration proposal or whatever, please comment.

    First, here are the ones I didn't test along with why:

    The first one I actually tested, also the first one to show up when looking for "bitbucket continuous integration" on Google is https://drone.io. The UI is really simple, I was able to set up tests for Pylint in a matter of minutes: https://drone.io/bitbucket.org/logilab/pylint. Tests are automatically launched when a new commit is pushed to Pylint's Bitbucket repository and that setup was done automatically.

    Trying to push Drone.io further, one missing feature is the ability to have different settings for my project, e.g. to launch tests on all the python flavor officially supported by Pylint (2.5, 2.6, 2.7, 3.2, 3.3, pypy, jython, etc.). Last but not least, the missing killer feature I want is the ability to launch tests on top of Pull Requests, which travis-ci supports.

    Then I gave http://wercker.com a shot, but got stuck at the Bitbucket repository selection screen: none were displayed. Maybe because I don't own Pylint's repository, I'm only part of the admin/dev team? Anyway, wercker seems appealing too, though the configuration using yaml looks a bit more complicated than drone.io's, but as I was not able to test it further, there's not much else to say.

    https://www.logilab.org/file/4758432/raw/wercker.png

    So for now the winner is https://drone.io, but the first one allowing me to test on several Python versions and to launch tests on pull requests will be the definitive winner! Bonus points for automating the release process and checking test coverage on pull requests as well.

    https://drone.io/drone3000/images/alien-zap-header.png

  • A retrospective of 10 years animating the pylint free software projet

    2013/11/25 by Sylvain Thenault

    was the topic of the talk I gave last saturday at the Capitol du Libre in Toulouse.

    Here are the slides (pdf) for those interested (in french). A video of the talk should be available soon on the Capitol du Libre web site. The slides are mirrored on slideshare (see below):


  • Pylint 1.0 released!

    2013/08/06 by Sylvain Thenault

    Hi there,

    I'm very pleased to announce, after 10 years of existence, the 1.0 release of Pylint.

    This release has a hell long ChangeLog, thanks to many contributions and to the 10th anniversary sprint we hosted during june. More details about changes below.

    Chances are high that your Pylint score will go down with this new release that includes a lot of new checks :) Also, there are a lot of improvments on the Python 3 side (notably 3.3 support which was somewhat broken).

    You may download and install it from Pypi or from Logilab's debian repositories. Notice Pylint has been updated to use the new Astroid library (formerly known as logilab-astng) and that the logilab-common 0.60 library includes some fixes necessary for using Pylint with Python3 as well as long-awaited support for namespace packages.

    For those interested, below is a comprehensive list of what changed:

    Command line and output formating

    • A new --msg-template option to control output, deprecating "msvc" and "parseable" output formats as well as killing --include-ids and --symbols options.
    • Fix spelling of max-branchs option, now max-branches.
    • Start promoting usage of symbolic name instead of numerical ids.

    New checks

    • "missing-final-newline" (C0304) for files missing the final newline.
    • "invalid-encoded-data" (W0512) for files that contain data that cannot be decoded with the specified or default encoding.
    • "bad-open-mode" (W1501) for calls to open (or file) that specify invalid open modes (Original implementation by Sasha Issayev).
    • "old-style-class" (C1001) for classes that do not have any base class.
    • "trailing-whitespace" (C0303) that warns about trailing whitespace.
    • "unpacking-in-except" (W0712) about unpacking exceptions in handlers, which is unsupported in Python 3.
    • "old-raise-syntax" (W0121) for the deprecated syntax raise Exception, args.
    • "unbalanced-tuple-unpacking" (W0632) for unbalanced unpacking in assignments (bitbucket #37).

    Enhanced behaviours

    • Do not emit [fixme] for every line if the config value 'notes' is empty
    • Emit warnings about lines exceeding the column limit when those lines are inside multiline docstrings.
    • Name check enhancement:
      • simplified message,
      • don't double-check parameter names with the regex for parameters and inline variables,
      • don't check names of derived instance class members,
      • methods that are decorated as properties are now treated as attributes,
      • names in global statements are now checked against the regular expression for constants,
      • for toplevel name assignment, the class name regex will be used if pylint can detect that value on the right-hand side is a class (like collections.namedtuple()),
      • add new name type 'class_attribute' for attributes defined in class scope. By default, allow both const and variable names.
    • Add a configuration option for missing-docstring to optionally exempt short functions/methods/classes from the check.
    • Add the type of the offending node to missing-docstring and empty-docstring.
    • Do not warn about redefinitions of variables that match the dummy regex.
    • Do not treat all variables starting with "_" as dummy variables, only "_" itself.
    • Make the line-too-long warning configurable by adding a regex for lines for with the length limit should not be enforced.
    • Do not warn about a long line if a pylint disable option brings it above the length limit.
    • Do not flag names in nested with statements as undefined.
    • Remove string module from the default list of deprecated modules (bitbucket #3).
    • Fix incomplete-protocol false positive for read-only containers like tuple (bitbucket #25).

    Other changes

    • Support for pkgutil.extend_path and setuptools pkg_resources (logilab-common #8796).
    • New utility classes for per-checker unittests in testutils.py
    • Added a new base class and interface for checkers that work on the tokens rather than the syntax, and only tokenize the input file once.
    • epylint shouldn't hang anymore when there is a large output on pylint'stderr (bitbucket #15).
    • Put back documentation in source distribution (bitbucket #6).

    Astroid

    • New API to make it smarter by allowing transformation functions on any node, providing a register_transform function on the manager instead of the register_transformer to make it more flexible wrt node selection
    • Use this new transformation API to provide support for namedtuple (actually in pylint-brain, logilab-astng #8766)
    • Better description of hashlib
    • Properly recognize methods annotated with abc.abstract{property,method} as abstract.
    • Added the test_utils module for building ASTs and extracting deeply nested nodes for easier testing.

  • Astroid 1.0 released!

    2013/08/02 by Sylvain Thenault

    Astroid is the new name of former logilab-astng library. It's an AST library, used as the basis of Pylint and including Python 2.5 -> 3.3 compatible tree representation, statical type inference and other features useful for advanced Python code analysis, such as an API to provide extra information when statistical inference can't overcome Python dynamic nature (see the pylint-brain project for instance).

    It has been renamed and hosted to bitbucket to make clear that this is not a Logilab dedicated project but a community project that could benefit to any people manipulating Python code (statistical analysis tools, IDE, browser, etc).

    Documentation is a bit rough but should quickly improve. Also a dedicated web-site is now online, visit www.astroid.org (or https://bitbucket.org/logilab/astroid for development).

    You may download and install it from Pypi or from Logilab's debian repositories.


  • PyLint 10th anniversary 1.0 sprint: day 3 - Sprint summary

    2013/06/20 by Sylvain Thenault

    Yesterday was the third and last day of the 10th anniversary Pylint sprint in Logilab's Toulouse office.

    Design

    To get started, we took advantage of this last day to have a few discussions about:

    • A "mode" feature gpylint has. It turns out that behind perhaps a few implementation details, this is something we definitly want into pylint (mode are specific configurations defined in the pylintrc and easilly recallable, they may even be specified per file).

    • How to avoid conflicts in the ChangeLog by using specific instruction in the commit message. We decided that a commit message should look like

      [my checker] do this and that. Closes #1234
      
      bla bla bla
      
      :release note: this will be a new item in the ChangeLog
      
      as well as anything until the end of the message
      

      now someone has to write the ChangeLog generation script so we may use this for post-1.0 releases

    • The roadmap. More on this later in this post.

    Code

    When we were not discussing, we were coding!

    • Anthony worked on having a template for the text reporter. His patch is available on Bitbucket but not yet integrated.
    • Julien and David pushed a bunch of patches on logilab-common, astroid and pylint for the Python 3.3 support. Not all tests are green on the pylint side, but much progress was done.
    • A couple other things were fixed, like a better "invalid name" message, stop complaining about string module being deprecated, etc.
    • A lot of patches have been integrated, from gpylint and others (e.g python 3 related)

    All in all, an impressive amount of work was achieved during this sprint:

    • A lot of new checks or enhanced behaviour backported from gpylint (Take a look at Pylint's ChangeLog for more details on this, the list is impressively long).
    • The transformation API of astroid now allows to customize the tree structure as well as the inference process, hence to make pylint smarter than ever.
    • Better python 3 support.
    • A few bugs fixed and some enhancements added.
    • The templating stuff should land with the CLI cleanup (some output-formats will be removed as well as the --include-ids and --symbols option).
    • A lot of discussions, especially regarding the future community development of pylint/astroid on Bitbucket. Short summary being: more contributors and integrators are welcome! We should drop some note somewhere to describe how we are using bitbucket's pull requests and tracker.

    Plan

    Now here is the 1.O roadmap, which is expected by the begining of July:

    • Green tests under Python 3, including specification of Python version in message description (Julien).
    • Finish template for text reporters (Anthony).
    • Update web site (David).

    And for later releases:

    • Backport mode from gpylint (Torsten).
    • Write ChangeLog update script (Sylvain).

    So many thanks to everyone for this very successful sprint. I'm excited about this forthcoming 1.0 release!


  • PyLint 10th anniversary 1.0 sprint: day 2

    2013/06/18 by Sylvain Thenault

    Today was the second day of the 10th anniversary Pylint sprint in Logilab's Toulouse office.

    This morning, we started with a presentation by myself about how the inference engine works in astroid (former astng). Then we started thinking all together about how we should change its API to be able to plug more information during the inference process. The first use-case we wanted to assert was namedtuple, as explained in http://www.logilab.org/ticket/8796.

    We ended up by addressing it by:

    • enhancing the existing transformation feature so one may register a transformation function on any node rather than on a module node only;
    • being able to specify, on a node instance, a custom inference function to use instead of the default (class) implementation.

    We would then be able to customize both the tree structure and the inference process and so to resolve the cases we were targeting.

    Once this was sufficiently sketched out, everyone got his own tasks to do. Here is a quick summary of what has been achieved today:

    • Anthony resumed the check_messages thing and finished it for the simple cases, then he started on having a template for text reported,
    • Julien and David made a lot of progress on the Python 3.3 compatibility, though not enough to get the full green test suite,
    • Torsten continued backporting stuff from gpylint, all of them having been integrated by the end of the day,
    • Sylvain implemented the new transformation API and had the namedtuple proof of concept working, and even some documentation! Now this have to be tested for more real-world uses.

    So things are going really well, and see you tomorrow for even more improvements to pylint!


  • PyLint 10th anniversary 1.0 sprint: day 1

    2013/06/17 by Sylvain Thenault

    Today was the first day of the Pylint sprint we organized using Pylint's 10th years anniversary as an excuse.

    So I (Sylvain) have welcome my fellow Logilab friends David, Anthony and Julien as well as Torsten from Google into Logilab's new Toulouse office.

    After a bit of presentation and talk about Pylint development, we decided to keep discussion for lunch and dinner and to setup priorities. We ended with the following tasks (picks from the pad at http://piratepad.net/oAvsUoGCAC):

    • rename astng to move it outside the logilab package,
    • Torsten gpylint (Google Pylint) patches review, as much as possible (but not all of them, starting by a review of the numberous internal checks Google has, seeing one by one which one should be backported upstream),
    • setuptools namespace package support (https://www.logilab.org/8796),
    • python 3.3 support,
    • enhance astroid (former astng) API to allow more ad-hoc customization for a better grasp of magic occuring in e.g. web frameworks (protocol buffer or SQLAlchemy may also be an application of this).

    Regarding the astng renaming, we decided to move on with astroid as pointed out by the survey on StellarSurvey.com

    In the afternoon, David and Julien tackled this, while Torsten was extracting patches from Google code and sending them to bitbucket as pulll request, Sylvain embrassing setuptools namespaces packages and Anthony discovering the code to spread the @check_message decorator usage.

    By the end of the day:

    • David and Julien submitted patches to rename logilab.astng which were quickly integrated and now https://bitbucket.org/logilab/astroid should be used instead of https://bitbucket.org/logilab/astng
    • Torsten submitted 5 pull-requests with code extracted from gpylint, we reviewed them together and then Torsten used evolve to properly insert those in the pylint history once review comments were integrated
    • Sylvain submitted 2 patches on logilab-common to support both setuptools namespace packages and pkgutil.extend_path (but not bare __path__ manipulation
    • Anthony discovered various checkers and started adding proper @check_messages on visit methods

    After doing some review all together, we even had some time to take a look at Python 3.3 support while writing this summary.

    Hopefuly, our work on forthcoming days will be as efficient as on this first day!


  • Pylint 10th years anniversary from June 17 to 19 in Toulouse

    2013/04/18 by Sylvain Thenault

    After a quick survey, we're officially scheduling Pylint 10th years anniversary sprint from monday, June 17 to wednesday, June 19 in Logilab's Toulouse office.

    There is still some room available if more people want to come, drop me a note (sylvain dot thenault at logilab dot fr).


  • Pylint development moving to BitBucket

    2013/04/12 by Sylvain Thenault

    Hi everyone,

    After 10 years of hosting Pylint on our own forge at logilab.org, we've decided to publish version 1.0 and move Pylint and astng development to BitBucket. There has been repository mirrors there for some time, but we intend now to use all BitBucket features, notably Pull Request, to handle various development tasks.

    There are several reasons behind this. First, using both BitBucket and our own forge is rather cumbersome, for integrators at least. This is mainly because BitBucket doesn't provide support for Mercurial's changeset evolution feature while our forge relies on it. Second, our forge has several usability drawbacks that make it hard to use for newcomers, and we lack the time to be responsive on this. Finally, we think that our quality-control process, as exposed by our forge, is a bit heavy for such community projects and may keep potential contributors away.

    All in all, we hope this will help to have a wider contributor audience as well as more regular maintainers / integrators which are not Logilab employees. And so, bring the best Pylint possible to the Python community!

    Logilab.org web pages will be updated to mention this, but kept as there is still valuable information there (eg tickets). We may also keep automatic tests and package building services there.

    So, please use https://bitbucket.org/logilab/pylint as main web site regarding pylint development. Bug reports, feature requests as well as contributions should be done there. The same move will be done for Pylint's underlying library, logilab-astng (https://bitbucket.org/logilab/astng). We also wish in this process to move it out of the 'logilab' python package. It may be a good time to give it another name, if you have any idea don't hesitate to express yourself.

    Last but not least, remember that Pylint home page may be edited using Mercurial, and that the new http://docs.pylint.org is generated using the content found in Pylint source doc subdirectory.

    Pylint turning 10 and moving out of its parents is probably a good time to thank Logilab for paying me and some colleagues to create and maintain this project!

    https://bitbucket-assetroot.s3.amazonaws.com/c/photos/2013/Apr/05/pylint-logo-1661676867-0_avatar.png

  • PyLint 10th years anniversary, 1.0 sprint

    2013/03/29 by Sylvain Thenault

    In a few week, pylint will be 10 years old (0.1 released on may 19 2003!). At this occasion, I would like to release a 1.0. Well, not exactly at that date, but not too long after would be great. Also, I think it would be a good time to have a few days sprint to work a bit on this 1.0 but also to meet all together and talk about pylint status and future, as more and more contributions come from outside Logilab (actually mostly Google, which employs Torsten and Martin, the most active contributors recently).

    The first thing to do is to decide a date and place. Having discussed a bit with Torsten about that, it seems reasonable to target a sprint during june or july. Due to personal constraints, I would like to host this sprint in Logilab's Toulouse office.

    So, who would like to jump in and sprint to make pylint even better? I've created a doodle so every one interested may tell his preferences: http://doodle.com/4uhk26zryis5x7as

    Regarding the location, is everybody ok with Toulouse? Other ideas are Paris, or Florence around EuroPython, or... <add your proposition here>.

    We'll talk about the sprint topics later, but there are plenty of exciting ideas around there.

    Please, answer quickly so we can move on. And I hope to see you all there!


  • Release of PyLint 0.27 / logilab-astng 0.24.2

    2013/02/28 by Sylvain Thenault

    Hi there,

    I'm very pleased to announce the release of pylint 0.27 and logilab-astng 0.24.2. There has been a lot of enhancements and bug fixes since the latest release, so you're strongly encouraged to upgrade. Here is a detailed list of changes:

    • #20693: replace pylint.el by Ian Eure version (patch by J.Kotta)
    • #105327: add support for --disable=all option and deprecate the 'disable-all' inline directive in favour of 'skip-file' (patch by A.Fayolle)
    • #110840: add messages I0020 and I0021 for reporting of suppressed messages and useless suppression pragmas. (patch by Torsten Marek)
    • #112728: add warning E0604 for non-string objects in __all__ (patch by Torsten Marek)
    • #120657: add warning W0110/deprecated-lambda when a map/filter of a lambda could be a comprehension (patch by Martin Pool)
    • #113231: logging checker now looks at instances of Logger classes in addition to the base logging module. (patch by Mike Bryant)
    • #111799: don't warn about octal escape sequence, but warn about o which is not octal in Python (patch by Martin Pool)
    • #110839: bind <F5> to Run button in pylint-gui
    • #115580: fix erroneous W0212 (access to protected member) on super call (patch by Martin Pool)
    • #110853: fix a crash when an __init__ method in a base class has been created by assignment rather than direct function definition (patch by Torsten Marek)
    • #110838: fix pylint-gui crash when include-ids is activated (patch by Omega Weapon)
    • #112667: fix emission of reimport warnings for mixed imports and extend the testcase (patch by Torsten Marek)
    • #112698: fix crash related to non-inferable __all__ attributes and invalid __all__ contents (patch by Torsten Marek)
    • Python 3 related fixes:
      • #110213: fix import of checkers broken with python 3.3, causing "No such message id W0704" breakage
      • #120635: redefine cmp function used in pylint.reporters
    • Include full warning id for I0020 and I0021 and make sure to flush warnings after each module, not at the end of the pylint run. (patch by Torsten Marek)
    • Changed the regular expression for inline options so that it must be preceeded by a # (patch by Torsten Marek)
    • Make dot output for import graph predictable and not depend on ordering of strings in hashes. (patch by Torsten Marek)
    • Add hooks for import path setup and move pylint's sys.path modifications into them. (patch by Torsten Marek)
    • pylint-brain: more subprocess.Popen faking (see #46273)
    • #109562 [jython]: java modules have no __doc__, causing crash
    • #120646 [py3]: fix for python3.3 _ast changes which may cause crash
    • #109988 [py3]: test fixes

    Many thanks to all the people who contributed to this release!

    Enjoy!


  • PyLint 0.26 is out

    2012/10/08 by Sylvain Thenault

    I'm very pleased to announce new releases of Pylint and underlying ASTNG library, respectivly 0.26 and 0.24.1. The great news is that both bring a lot of new features and some bug fixes, mostly provided by the community effort.

    We're still trying to make it easier to contribute on our free software project at Logilab, so I hope this will continue and we'll get even more contritions in a near future, and an even smarter/faster/whatever pylint!

    For more details, see ChangeLog files or http://www.logilab.org/project/pylint/0.26.0 and http://www.logilab.org/project/logilab-astng/0.24.1

    So many thanks to all those who made that release, and enjoy!


  • Sprint PyLint @ PyConFr 2012

    2012/08/20 by Sylvain Thenault

    Un sprint PyLint est organisé dans le cadre de la conférence PyConFR, les 13 et 14 septembre à Paris. Si vous voulez améliorer PyLint, c'est l'occasion : venez avec vos bugs et repartez sans !

    Les débutants sont bienvenus, une introduction au code de Pylint sera réalisée en début de sprint. Une expérience avec le module ast de la librairie standard est un plus.

    Croissants et café offerts par l'organisation, merci de vous inscrire pour faciliter la logistique. Voir avec Boris pour plus d'informations (merci à lui !)


  • PyLint 0.25.2 and related projects released

    2012/07/18 by Sylvain Thenault

    I'm pleased to announce the new release of Pylint and related projects (i.e. logilab-astng and logilab-common)!

    By installing PyLint 0.25.2, ASTNG 0.24 and logilab-common 0.58.1, you'll get a bunch of bug fixes and a few new features. Among the hot stuff:

    • PyLint should now work with alternative python implementations such as Jython, and at least go further with PyPy and IronPython (but those have not really been tested, please try it and provide feedback so we can improve their support)
    • the new ASTNG includes a description of dynamic code it is not able to understand. This is handled by a bitbucket hosted project described in another post.

    Many thanks to everyone who contributed to these releases, Torsten Marek / Boris Feld in particular (both sponsored by Google by the way, Torsten as an employee and Boris as a GSoC student).

    Enjoy!


  • Introducing the pylint-brain project

    2012/07/18 by Sylvain Thenault

    Huum, along with the new PyLint release, it's time to introduce the PyLint-Brain project I've recently started.

    Despite its name, PyLint-Brain is actually a collection of extensions for ASTNG, with the goal of making ASTNG smarter (and this directly benefits PyLint) by describing stuff that is too dynamic to be understood automatically (such as functions in the hashlib module, defaultdict, etc.).

    The PyLint-Brain collection of extensions is developped outside of ASTNG itself and hosted on a bitbucket project to ease community involvement and to allow distinct development cycles. Basically, ASTNG will include the PyLint-Brain extensions, but you may use earlier/custom versions by tweaking your PYTHONPATH.

    Take a look at the code, it's fairly easy to contribute new descriptions, and help us make pylint smarter!


  • Mêlée numérique 2012: État de l'art Big Data

    2012/05/03 by Sylvain Thenault
    http://www.logilab.org/file/92705?vid=download

    J'ai passé ce jeudi 26 avril à la Mêlée numérique à Toulouse.

    Après une mini-conf d'une heure sur l'état de l'art de l'Open Data, j'ai suivi l'après midi "état de l'art Big Data" au même format.

    Big Data vu par SGI

    Ma première surprise a été d'apprendre où était caché SGI (vous vous rappelez peut-être les postes Indigo qu'on trouvait pour faire du graphisme et de l'animation...) depuis tout ce temps : et bien non, ils ne sont pas morts mais montent des calculateurs pour des grands comptes. Le premier intervenant était donc M. Carsalade, responsable infrastructure chez SGI, qui a pris quelques exemples d'applications et d'infrastructures "Big Data" (petabytes de données) menées par SGI.

    Parmi les applications citées : calculateurs chez NOAA (sorte de Météo France aux US) ou Total (analyse des sols), Cosmos Project (15 tera de ram...), génomiques

    SGI déploie par ex. :

    • 500 000 serveurs SGI chez Amazon pour S3/eC2, site web, AWS...
    • 300 000 serveurs SGI chez Microsoft pour Live Search (Bing, Exchange, MSN, etc.)

    La technologie est souvent basée sur HADOOP, qui permet la recherche en parallèle sur un cloud, basée sur le principe map / reduce initiée par Google.

    On note l'évolution des technologies dans le temps et par volume croissant:

    • OLTP (données structurées),
    • data warehouse (données essentiellement structurées),
    • Big Data (données essentiellement non structurées)

    Il conclut que Big Data, c'est :

    • la capacité de stockage de données, et celle de l'agrandir au fur et à mesure du besoin,
    • travailler sur ces données (HADOOP), les analyser et les visualiser,
    • mais aussi archiver ces données, problématique souvent ignorée au premier abord mais pourtant nécessaire.

    Big Data vu par une PME spécialisée

    La présentation suivante de M.Royer (Datasio) est un peu plus technique.

    Pour commencer, une liste des sources de données problématiques potentielles (i.e. la production ne s'arrête pas) :

    • production par des réseaux d'observation autonome (capteurs météo, GPS, RFID, balises Argos...),
    • données dépendantes d'une communauté d'utilisateurs et d'individus instrumentés,
    • données produites plus vite qu'on ne les traite,
    • "on verra le traitement plus tard".

    Synthèse de ces problèmes : les "3 V" du Big Data: Volume / Variété / Vélocité.

    Les techniques autour de Big Data promettent de :

    • faciliter la collecte et l'aggrégation (mesurer les opérations, acquérir tous les flux possibles, stocker les mesures brutes)
    • valoriser le capital de données (découvrir après coup des opportunités inexploitées, outils de fouille adaptés aux gros volumes, extraire et distiller l'information)

    Il revient sur HADOOP en quelques mots :

    • solution Open Source, issu de la fondation Apache,
    • à l'initiative de Yahoo via un essaimage Hortonworks
    • c'est un projet en maturation, avec une communauté active, mais des branches de code variées,
    • constitué d'un système de fichier distribué avec redondance (parallélisation des données) et possibilité map / reduce (parallélisation des tâches à effectuer sur les données)

    Si Big Data est un nouveau terme pour une problématique qui n'est pas nouvelle, une différence liée à la technique map / reduce les traitements sont effectués sur les serveurs qui hébergent les données au lieu de pousser les données vers un calculateur. Attention au fait cependant que pour fonctionner, les algorithmes doivent fonctionner de manière indépendante sur un sous-ensemble indéterminé de données (donc finalement indépendamment sur chaque "donnée"). Enfin, on se concentre sur l'efficience de la création et de la lecture des données, à l'inverse des bases de données traditionnelles qui se concentrent également sur la mise à jour et la suppression.

    Je ne sais pas s'il y avait une conclusion, la présentation a été abrégée faute de temps.

    Big Data vu par Météo France

    La dernière présentation était celle de M.Beuraud de Météo France dont la problématique, pas simple mais à laquelle nous sommes tous sensibles, est la prévision numérique du temps.

    Il note tout d'abord que la qualité des prévisions a augmenté : la qualité d'une prévison à 48h aujourd'hui vaut prévision à 24h il y a 15 ans en lien avec l'augmentation des performances du centre de calcul HPC de Météo France à Toulouse (évolution matérielle tous les 3 ans) :

    • 2 GFlops en 1991 (date de l'ouverture du centre), basé sur des machines Cray 2,
    • 100 TFlops en 2009, basé sur des machines NEC SX9

    Le volume de données étudiées est maintenant beaucoup plus important, principalement du fait de la constellation de satellites qui s'est développée et qui produit un volume beaucoup plus important que les mesures conventionnelles (au sol). On a vu un "déluge de données" satellitaires depuis 2010. D'un point de vue stockage, le site est passé de 20Go en 1991 à plusieurs pétaoctets aujourd'hui.

    De par les différentes contraintes extérieures (données à fournir aux clients), une prévision à 24h doit être faite en 25 minutes. De plus, la puissance de calcul nécessaire augmente sans cesse notamment à cause des facteurs suivants (en plus du volume de données à analyser qui augmente) :

    • maille de plus en plus petite,
    • couplage de modèles de plus en plus nombreux,
    • prévision ensembliste : on lance X fois le même modèle avec des entrées différentes pour voir la stabilité de la prédiction.

    A noter qu'ici, on n'est pas dans des technos de type HADOOP.

    Il conclut que le volume de données à traiter va continuer à grandir, et que la gestion des données est l'enjeu majeur de la décennie qui s'ouvre.

    Conclusion

    J'ai été surpris de voir l'angle d'approche pour la présentation d'une thématique Big Data, qui était pour moi (novice je l'avoue) plus liée aux technologies Web. J'ai finalement trouvé que c'était intéressant de remettre ça avec cette perspective, et ainsi de replacer ce que recouvrent finalement les mots Big Data. Encore un grand mot qui veut tout et rien dire quoi :p


  • Mélée numérique 2012: État de l'art Open Data

    2012/04/27 by Sylvain Thenault
    http://www.logilab.org/file/92705?vid=download

    J'ai passé ce jeudi 26 avril à la Mélée numérique à Toulouse.

    J'y ai assisté à une mini-conf d'une heure sur l'état de l'art de l'Open Data. Comme d'habitude, je conseillerais plutôt, lors des salons de ce type, d'aller voir les conférences sur des thèmes qui vous sont inconnus, sous peine de ne pas apprendre grand chose. C'est resté pas trop mal, et voici ce que j'ai retiré de cette présentation conjointe de Bluenove, et Inno3.

    Data, c'est quoi exactement ?

    Dans le cadre de l'Open Data la donnée est le matériaux brute. C'est une valeur, une observation. Ce n'est pas une information, qui recoupe et interprète plusieurs données.

    Le recoupement de données permet de créer des informations de valeurs. Cependant certaines données n'ont pas vocation à être ouvertes (ex. données stratégiques, personnelles, défense).

    Qui sont les acteurs de l'Open Data ?

    On distingue :

    Qui a ouvert ses données ?

    En France : Étalab, 16 ministères, 5 administrations publiques, 2 régions, 5 départements, 11 métropoles, 7 municipalités, 3 grandes entreprises (réseau férré, sncf, la poste), 4 initiatives culturels, PS...

    Dans le monde: 28 pays, environ 120 localités de toutes tailles. On voit se former des initiatives continentales,

    Pour quels résultats ?

    • Un nouveau type d'information (NR issu d'une collaboration journaliste/développeur/graphiste), plus ou moins couvert sous le terme "Data viz" (eg OWNI)
    • Des applications diverses, parfois issues de concours (eg application téléphone Tourisme 71)

    Quels sont les freins et incitations ?

    Il y a une incitation/obligation venant de l'Europe (2003) et de l'état (2006) pour les acteurs publics, les acteurs privés délégataires d'un service public ou monopolistiques. On peut ajouter les modèles économiques basés sur la société de l'information (eg http://www.openstreetmap.org/ qui crée des données ouvertes collaborativement depuis 2006)

    Les freins viennent :

    • des données non diffusables,
    • d'une cohabitation parfois difficile avec Loi informatique et liberté / CNIL (le recoupement de plusieur sources peut finir par redonner des données "personnelles").

    De plus cette incitation à la transparence crée nouveaux rapport entre secteur public et privé (je ne m'en plaindrai pas personnellement :p ).

    Quels droits / quelles licences sur les données ?

    Rappel : la propriété intellectuelle recrée une notion similaire à la propriété matérielle mais sur des oeuvres. Les données ne sont pas soumise à la propriété intellectuelle. Les données originelles, ainsi qu'une base de données à forte valeur ajoutée, ou encore les signes distinctifs (marque, nom de domaine, logo, etc) sont considérés ou considérables comme des oeuvres.

    Il faut donc une gestion stratégique des différents droits de propriété intellectuelle. Que faut-il partager ou retenir ? Quel est l'encadrement souhaité ? Copyleft (eg GPL) ou non ? Compatibilité entre jeux de données ?

    Aujourd'hui on a comme licenses pour les données :

    • les licences basées sur le droit d'auteur (CC)
    • les licences basées sur la loi de 1978 (droit public en france, uniquement pour collectivité, pas de propriété intellectuelle) (LIP et APIE)
    • les licences spécialisées (ODBL, PDDL, ODC-By créées par Open knowledge foundation)
    • les licences dédiées (Licence Ouverte)

    En France (dans l'administration publique ?) l'ODBL et la Licence Ouverte sont principalement utilisées.

    En Europe et à l'étranger, on trouve plutôt l'ODBL, CC-0 et autres licences dédiées.

    Et l'Open Data dans l'entreprise ?

    Bluenove a mené une enquête auprès de grands groupes. Quelques résultats (l'intégralité est publiée dans un petit livre blanc dont j'ai un exemplaire) :

    • les bénéfices attendus de l'ouverture et de la réutilisation sont avant tout d'améliorer la satisfaction des clients, et en dernier lieu de se différencier de ses concurrents
    • les obstacles ressentis : le besoin de contrôler la réutilisation de ses données, la peur de donner l'accés à ses données aux concurents ou encore la frilosité à la réutilisation de données des autres (problème potentiel de fraicheur et/ou qualité des données)

    43 % des entreprises sondées disent qu'une réfléxion autour de l'Open Data est en cours évolution.

    Conclusion

    Aujourd'hui, les licences sont matures et ne posent plus vraiment problème. On peut espérer avoir rapidement plus de données et d'acteurs dans l'Open Data. Cependant dans le public comme dans le privé une difficulté est d'encadrer la production : motiver la production de données, accueillir les résultats et gérer la diffusion (qui a dit CubicWeb ? En toute objectivité :p ).

    NR: On notera l'absence de discussion autour des formats de publication de données notamment. Pour conclure, j'aurais plutôt appelé ça état les lieux que état de l'art, même si ça reste un effort de synthèse appréciable.


  • Helping pylint to understand things it doesn't

    2011/10/10 by Sylvain Thenault

    The latest release of logilab-astng (0.23), the underlying source code representation library used by PyLint, provides a new API that may change pylint users' life in the near future...

    It aims to allow registration of functions that will be called after a module has been parsed. While this sounds dumb, it gives a chance to fix/enhance the understanding PyLint has about your code.

    I see this as a major step towards greatly enhanced code analysis, improving the situation where PyLint users know that when running it against code using their favorite framework (who said CubicWeb? :p ), they should expect a bunch of false positives because of black magic in the ORM or in decorators or whatever else. There are also places in the Python standard library where dynamic code can cause false positives in PyLint.

    The problem

    Let's take a simple example, and see how we can improve things using the new API. The following code:

    import hashlib
    
    def hexmd5(value):
        """"return md5 checksum hexadecimal digest of the given value"""
        return hashlib.md5(value).hexdigest()
    
    def hexsha1(value):
        """"return sha1 checksum hexadecimal digest of the given value"""
        return hashlib.sha1(value).hexdigest()
    

    gives the following output when analyzed through pylint:

    [syt@somewhere ~]$ pylint -E example.py
    No config file found, using default configuration
    ************* Module smarter_astng
    E:  5,11:hexmd5: Module 'hashlib' has no 'md5' member
    E:  9,11:hexsha1: Module 'hashlib' has no 'sha1' member
    

    However:

    [syt@somewhere ~]$ python
    Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53)
    [GCC 4.5.2] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import smarter_astng
    >>> smarter_astng.hexmd5('hop')
    '5f67b2845b51a17a7751f0d7fd460e70'
    >>> smarter_astng.hexsha1('hop')
    'cffb6b20e0eef296772f6c1457cdde0049bdfb56'
    

    The code runs fine... Why does pylint bother me then? If we take a look at the hashlib module, we see that there are no sha1 or md5 defined in there. They are defined dynamically according to Openssl library availability in order to use the fastest available implementation, using code like:

    for __func_name in __always_supported:
        # try them all, some may not work due to the OpenSSL
        # version not supporting that algorithm.
        try:
            globals()[__func_name] = __get_hash(__func_name)
        except ValueError:
            import logging
            logging.exception('code for hash %s was not found.', __func_name)
    

    Honestly I don't blame PyLint for not understanding this kind of magic. The situation on this particular case could be improved, but that's some tedious work, and there will always be "similar but different" case that won't be understood.

    The solution

    The good news is that thanks to the new astng callback, I can help it be smarter! See the code below:

    from logilab.astng import MANAGER, scoped_nodes
    
    def hashlib_transform(module):
        if module.name == 'hashlib':
            for hashfunc in ('sha1', 'md5'):
                module.locals[hashfunc] = [scoped_nodes.Class(hashfunc, None)]
    
    def register(linter):
        """called when loaded by pylint --load-plugins, register our tranformation
        function here
        """
        MANAGER.register_transformer(hashlib_transform)
    

    What's in there?

    • A function that will be called with each astng module built during a pylint execution, i.e. not only the one that you analyses, but also those accessed for type inference.
    • This transformation function is fairly simple: if the module is the 'hashlib' module, it will insert into its locals dictionary a fake class node for each desired name.
    • It is registered using the register_transformer method of astng's MANAGER (the central access point to built syntax tree). This is done in the pylint plugin API register callback function (called when module is imported using 'pylint --load-plugins'.

    Now let's try it! Suppose I stored the above code in a 'astng_hashlib.py' module in my PYTHONPATH, I can now run pylint with the plugin activated:

    [syt@somewhere ~]$ pylint -E --load-plugins astng_hashlib example.py
    No config file found, using default configuration
    ************* Module smarter_astng
    E:  5,11:hexmd5: Instance of 'md5' has no 'hexdigest' member
    E:  9,11:hexsha1: Instance of 'sha1' has no 'hexdigest' member
    

    Huum. We have now a different error :( Pylint grasp there are some md5 and sha1 classes but it complains they don't have a hexdigest method. Indeed, we didn't give a clue about that.

    We could continue on and on to give it a full representation of hashlib public API using the astng nodes API. But that would be painful, trust me. Or we could do something clever using some higher level astng API:

    from logilab.astng import MANAGER
    from logilab.astng.builder import ASTNGBuilder
    
    def hashlib_transform(module):
        if module.name == 'hashlib':
        fake = ASTNGBuilder(MANAGER).string_build('''
    
    class md5(object):
      def __init__(self, value): pass
      def hexdigest(self):
        return u''
    
    class sha1(object):
      def __init__(self, value): pass
      def hexdigest(self):
        return u''
    
    ''')
        for hashfunc in ('sha1', 'md5'):
            module.locals[hashfunc] = fake.locals[hashfunc]
    
    def register(linter):
        """called when loaded by pylint --load-plugins, register our tranformation
        function here
        """
        MANAGER.register_transformer(hashlib_transform)
    

    The idea is to write a fake python implementation only documenting the prototype of the desired class, and to get an astng from it, using the string_build method of the astng builder. This method will return a Module node containing the astng for the given string. It's then easy to replace or insert additional information into the original module, as you can see in the above example.

    Now if I run pylint using the updated plugin:

    [syt@somewhere ~]$ pylint -E --load-plugins astng_hashlib example.py
    No config file found, using default configuration
    

    No error anymore, great!

    What's next?

    This fairly simple change could quickly provide great enhancements. We should probably improve the astng manipulation API now that it's exposed like that. But we can also easily imagine a code base of such pylint plugins maintained by each community around a python library or framework. One could then use a plugins stack matching stuff used by its software, and have a greatly enhanced experience of using pylint.

    For a start, it would be great if pylint could be shipped with a plugin that explains all the magic found in the standard library, wouldn't it? Left as an exercice to the reader!


  • Pylint 0.24 / logilab-astng 0.22

    2011/07/21 by Sylvain Thenault

    Hi there!

    I'm pleased to announce new releases of pylint and its underlying library logilab-astng. See http://www.logilab.org/project/pylint/0.24.0 and http://www.logilab.org/project/logilab-astng/0.22.0 for more info.

    Those releases include mostly fixes and a few enhancements. Python 2.6 relative / absolute imports should now work fine and Python 3 support has been enhanced. There are still two remaining failures in astng test suite when using python 3, but we're unfortunatly missing resources to fix them yet.

    Many thanks to everyone who contributed to this release by submitting patches or by participating to the latest bugs day.


  • pylint bug day #3 on july 8, 2011

    2011/07/04 by Sylvain Thenault

    Hey guys,

    we'll hold the next pylint bug day on july 8th 2011 (friday). If some of you want to come and work with us in our Paris office, you'll be welcome.

    You can also join us on jabber / irc:

    I know the announce is a bit late, but I hope some of you will be able to come or be online anyway!

    Regarding the program, the goal is to decrease the number of tickets in the tracker. I'll try to do some triage earlier this week so you'll get a chance to talk about your super-important ticket that has not been selected. Of course, if you intend to work on it, there is a bigger chance of it being fixed next week-end ;)


  • pylint bug days #2 report

    2010/04/19 by Sylvain Thenault

    First of all, I've to say that pylint bugs day wasn't that successful in term of 'community event': I've been sprinting almost alone. My Logilab's felows were tied to customer projects, and no outside people shown up on jabber. Fortunatly Tarek Ziade came to visit us, and that was a nice opportunity to talk about pylint, distribute, etc ... Thank you Tarek, you saved my day ;)

    As I felt a bit alone, I decided to work on somethings funnier than bug fixing: refactoring!

    First, I've greatly simplified the command line: enable-msg/enable-msg-cat/enable-checker/enable-report and their disable-* counterparts were all merged into single --enable/--disable options.

    I've also simplified "pylint --help" output, providing a --long-help option to get what we had before. Generic support in `logilab.common.configuration of course.

    And last but not least, I refactored pylint so we can have multiple checkers with the same name. The idea behind this is that we can split checker into smaller chunks, basically only responsible for one or a few related messages. When pylint runs, it only uses necessary checkers according to activated messages and reports. When all checkers will be splitted, it should improve performance of "pylint --error-only".

    So, I can say I'm finally happy with the results of that pylint bugs day! And hopefuly we will be more people for the next edition...


  • pylint bugs day #2 on april 16, 2010

    2010/03/22 by Sylvain Thenault

    Hey guys,

    we'll hold the next pylint bugs day on april 16th 2010 (friday). If some of you want to come and work with us in our Paris office, you'll be much welcome.

    Else you can still join us on jabber / irc:

    See you then!


  • pylint bug day next wednesday!

    2009/11/23 by Sylvain Thenault

    Remember that the first pylint bug day will be held on wednesday, november 25, from around 8am to 8pm in the Paris (France) time zone.

    We'll be a few people at Logilab and hopefuly a lot of other guys all around the world, trying to make pylint better.

    Join us on the #public conference room of conference.jabber.logilab.org, or if you prefer using an IRC client, join #public on irc.logilab.org which is a gateway to the jabber forum. And if you're in Paris, come to work with us in our office.

    People willing to help but without knowledge of pylint internals are welcome, it's the perfect occasion to learn a lot about it, and to be able to hack on pylint in the future!


  • First Pylint Bug Day on Nov 25th, 2009 !

    2009/10/21 by Sylvain Thenault
    http://www.logilab.org/image/18785?vid=download

    Since we don't stop being overloaded here at Logilab, and we've got some encouraging feedback after the "Pylint needs you" post, we decided to take some time to introduce more "community" in pylint.

    And the easiest thing to do, rather sooner than later, is a irc/jabber synchronized bug day, which will be held on Wednesday november 25. We're based in France, so main developpers will be there between around 8am and 19pm UTC+1. If a few of you guys are around Paris at this time and wish to come at Logilab to sprint with us, contact us and we'll try to make this possible.

    The focus for this bug killing day could be:

    • using logilab.org tracker : getting an account, submitting tickets, triaging existing tickets...
    • using mercurial to develop pylint / astng
    • guide people in the code so they're able to fix simple bugs

    We will of course also try to kill a hella-lotta bugs, but the main idea is to help whoever wants to contribute to pylint... and plan for the next bug-killing day !

    As we are in the process of moving to another place, we can't organize a sprint yet, but we should have some room available for the next time, so stay tuned :)


  • New pylint/astng release, but... pylint needs you !

    2009/08/27 by Sylvain Thenault

    After several months with no time to fix/enhance pylint beside answering email and filing tickets, I've finally tackled some tasks yesterday night to publish bug fixes releases ([1] and [2]).

    The problem is that we don't have enough free time at Logilab to lower the number of tickets in pylint tracker page . If you take a look at the ticket tab, you'll see a lot of pendings bug and must-have features (well, and some other less necessary...). You can already easily contribute thanks to the great mercurial dvcs, and some of you do, either by providing patches or by reporting bugs (more tickets, iiirk ! ;) Thank you all btw !!

    Now I was wondering what could be done to make pylint going further, and the first ideas which came to my mind was :

    • do ~3 days sprint
    • do some 'tickets killing' days, as done in some popular oss projects

    But for this to be useful, we need your support, so here are some questions for you:

    • would you come to a sprint at Logilab (in Paris, France), so you can meet us, learn a lot about pylint, and work on tickets you wish to have in pylint?
    • if France is too far away for most people, would you have another location to propose?
    • would you be on jabber for a tickets killing day, providing it's ok with your agenda? if so, what's your knowledge of pylint/astng internals?

    you may answer by adding a comment to this blog (please register first by using the link at the top right of this page) or by mail to sylvain.thenault@logilab.fr. If we've enough positive answers, we'll take the time to organize such a thing.


  • iclassmethod decorator to define both a class and an instance method in one go

    2009/04/28 by Sylvain Thenault

    You'll find in the logilab.common.decorators module the iclassmethod decorator which may be pretty handy in some cases as it allows methods to be both called as class methods or as instance methods. In the first case the first argument will be the class and the second case it will be the instance.

    Example extracted (and adapted for simplicity) from CubicWeb:

    from logilab.common.decorators import iclassmethod
    
    class Form(object):
      _fields_ = []
    
      def __init__(self):
          self.fields = list(self._fields_)
    
      @iclassmethod
      def field_by_name(cls_or_self, name):
          """return field with the given name and role"""
          if isinstance(cls_or_self, type):
              fields = cls_or_self._fields_
          else:
              fields = cls_or_self.fields
          for field in fields:
              if field.name == name:
                  return field
          raise Exception('FieldNotFound: %s' % name)
    

    Example session:

    >>> from logilab.common import attrdict
    >>> f = Form()
    >>> f.fields.append(attrdict({'name': 'something', 'value': 1})
    >>> f.field_by_name('something')
    {'name': 'something', 'value': 1}
    >>> Form.field_by_name('something')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<stdin>", line 15, in field_by_name
    Exception: FieldNotFound: something
    

    So we get a field_by_name method which will act differently (actually use different input data) when called as instance method or as class method.

    Also notice the attrdict trick that can also be achieved with the Python 2.6 named tuple.


  • new pylint / astng / common releases

    2009/03/25 by Sylvain Thenault
    http://janckos.net/blog/wp-content/uploads/2008/08/python.png

    I'm pleased to announce releases of pylint 0.18, logilab-astng 0.19 and logilab-common 0.39. All these packages should now be cleanly available through easy install.

    Also, happy pylint users will get:

    • fixed python 2.6 support (pylint/astng tested from 2.4 to 2.6)
    • get source code (and so astng) for zip/egg imports
    • some understanding of the property decorator and of unbound methods
    • some false positives fixed and others minor improvments

    See projects home page and ChangeLog for more information:

    http://www.logilab.org/project/pylint http://www.logilab.org/project/logilab-astng http://www.logilab.org/project/logilab-common

    Please report any problem / question to the python-projects@lists.logilab.org mailing-list.

    Enjoy!


  • broken easy_install support

    2009/03/25 by Sylvain Thenault
    http://3.bp.blogspot.com/_lh41g82r7rk/SHIY6tMEk-I/AAAAAAAAABQ/Xh33EO1oa-U/s200/system-software-install48b.png

    I recently understood why easy_install wasn't able to find so many of our packages anymore.

    The problem was due to a recent change on our website. The project page was ajaxified, and since easy_install uses some screenscrapping techniques to get distribution archives, it can not find the files it is looking for.

    To fix this, we should make our tarballs downloadable from PyPI, by using

    python setup.py register sdist upload
    

    instead of the current:

    python setup.py register
    

    Uploading our public python software packages to PyPI will make them easy_installable in a breeze !


  • Instrumentation of google appengine's datastore.

    2008/06/23 by Sylvain Thenault

    Here is a piece of code I've written which I thought may be useful to some other people...

    You'll find here a simple python module to use with the Google AppEngine SDK to monkey patch the datastore API in order to get an idea of the calls performed by your application.

    To instrument of the datastore, put at the top level of your handler file

    import instrdatastore
    

    Note that it's important to have this before any other import in your application or in the google package to avoid that some modules will use the unpatched version of datastore functions (and hence calls to those functions wouldn't be considered).

    Then add at the end of your handler function

    instrdatastore.print_info()
    

    The handler file should look like this:

    """my handler file with datastore instrumenting activated"""
    import instrdatastore
    
    # ... other initialization code
    
    # main function so this handler module is cached
    def main():
      from wsgiref.handlers import CGIHandler
      from ginco.wsgi.handler import ErudiWSGIApplication
      application = ErudiWSGIApplication(config, vreg=vreg)
      CGIHandler().run(application)
      instrdatastore.print_info()
    
    if __name__ == "__main__":
      main()
    

    Now you should see in your logs the number of Get/Put/Delete/Query which has been done during request processing

    2008-06-23 06:59:12 - (root) WARNING: datastore access information
    2008-06-23 06:59:12 - (root) WARNING: nb Get: 2
    2008-06-23 06:59:12 - (root) WARNING: arguments (args, kwargs):
    ((datastore_types.Key.from_path('EGroup', u'key_users', _app=u'winecellar'),), {})
    ((datastore_types.Key.from_path('EUser', u'key_test@example.com', _app=u'winecellar'),), {})
    2008-06-23 06:59:12 - (root) WARNING: nb Query: 1
    2008-06-23 06:59:12 - (root) WARNING: arguments (args, kwargs):
    (({'for_user =': None}, 'EProperty'), {})
    2008-06-23 06:59:58 - (root) WARNING: nb Put: 1
    2008-06-23 06:59:58 - (root) WARNING: arguments (args, kwargs):
    (({u'login': None, u'last_usage_time': 1214204398.2022741, u'data': ""},), {})
    

    I'll probably extend this as the time goes. Also notice you may encounter some problems with the automatic reloading feature of the dev app server when instrumentation is activated, in which case you should simply restart the web server.


back to pagination (10 results)