subscribe to this blog

Logilab.org - en VF

Des nouvelles de Logilab et de nos projets sous licences libres, ainsi que des sujets qui nous tiennent à cœur (Python, Linux, Debian, le web sémantique, le calcul scientifique...)

show 67 results
  • 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 !


  • BestOfWeb 2015

    2015/06/11 by Adrien Di Mascio

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

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

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

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

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

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

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

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

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

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

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

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


  • KanbanDay 2015

    2015/06/02 by Nicolas Chauvat

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

    Management Visuel

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

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

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

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

    /file/293145/raw

    Gribouille Académie

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

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

    /file/293142/raw

    Plénières

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

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

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

    /file/293141/raw

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

    Autres ressources

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

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

    Conclusion

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


  • Retour sur la journée conteneurs dans le cadre de Open Source Innovation Spring

    2015/04/07 by Arthur Lutz

    Logilab a co-organisé la demi-journée sur les conteneurs dans le cadre du Printemps de l'innovation open source (Open Source Innovation Spring). Voici une partie des choses qui y furent dites.

    Open Source Innovation Spring

    AlterWay a commencé par une introduction expliquant pourquoi docker est si hype en ce moment. Quelques bémols ont été placés sur les questions de sécurité et les systèmes de fichiers utilisés par défaut (AUFS n'est pas dans le kernel linux officiel, des alternatives sont à l'étude).

    Une partie de l'écosystème autour de Docker a été mentionné :

    Ensuite Normation a présenté la gestion de configuration et Docker, avec de grandes questions générales sur le déploiement de serveurs, leur durée de vie, leur transformation, etc.

    Logilab & Mozilla

    Logilab a présenté l'utilisation conjointe de Salt Mercurial et Docker pour appliquer les bonnes pratiques du développement logiciel à la gestion d'infrastructures. Les supports de présentation sont sur http://slides.logilab.fr/osis/osis (aussi sur slideshare).

    Normation a ensuite présenté les fondements techniques des conteneurs, à savoir les fonctionnalités du noyau linux qui ont permis leur essor. Petit historique sur les cgroups, avec les idées d'origine sur les processus dans Unix, mais aussi les bonnes idées apportées par Plan 9 (et qui ont ensuite été reprises par Linux). On a vu des choses sur les chroots, les namespaces, fakeroot, ip netns, les informations dans /proc/<pid>/ns, et les systèmes de fichier d'union utilisé par les conteneurs : aufs, unionfs, overlayfs, fuse.

    Intervenants de la journée

    Ensuite deux démonstrations ont été présentées :

    • Utilisation de docker et docker-swarm sur amazon ec2 pour déployer une application html5 : CircleCI lit le dépôt git de l'application, construit l'image Docker et l'ajoute au hub puis pilote docker-swarm pour qu'elle soit déployée.
    • Utilisation de plusieurs plate-formes de cloud (Azure, Numergy, CloudWatt) pour déployer un conteneur docker sur plusieurs clouds en parallèle.

    Deux retours d'expérience par Theodo et Deliverous ont conclu la journée.


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


  • PyconFR 2014 : jour 1, bus de communication, packaging et fin

    2014/11/04 by Arthur Lutz

    Suite à :

    XBUS

    Florent Aide nous a présenté son projet XBUS, un bus de communication pour les applications. L'idée est de gérer l'historique : pour faire parler des applications métier entre elles, on les connecte toutes au même bus. Dans certains cas, notamment quand la sécurité des données est en jeux, l'application qui traite le message renvoie un accusé de réception et de traitement (ACK).

    Côté technique, il s'agit de :

    • un cœur écrit en Go
    • zmq pour la communication
    • Python pour la logique

    Lors des questions un projet similaire a été mentionné : autobahn. Le projet XBUS est libre et publié sur bitbucket.

    Comment le packaging m'a simplifié la vie

    Étant donné qu'à Logilab, nous avons des avis assez arrêté sur les questions de packaging, je suis allé voir cette conférence.

    Xavier Ordoquy nous a présenté en détail virtualenv (pyvenv directement dans python à partir de 3.4) ainsi que l'outil pip.

    Historiquement pypi a été instable, mais la situation s'est améliorée depuis qu'il est sur un CDN. Il y a un travail en cours sur la sécurité (vérification d'intégrité, ssl obligatoire etc). devpi permet d'avoir un pypi en interne comme cache, mais aussi comme système de "staging" avant de publier sur le pypi "officiel".

    Selon Xavier, la guerre des distutils, python.packaging, distutils2, distribute, etc est finie. Il faut à présent utiliser setuptools et le connaître sur le bouts des doigts. Xavier nous recommande de copier un setup.py pour démarrer nos projets, par exemple celui de sentry.

    Côté numéro de version, il faut aller lire la PEP440 Version Identification and Dependency Specification.

    extra_requires permet de faire : pip install sentry[postgres] qui installe sentry mais aussi les dépendances pour le faire marcher avec PostgreSQL.

    Côté packaging, il va falloir selon Christophe apprendre à utiliser wheel et stevedore (code).

    Lors des questions, un membre du public mentionne le projet diecutter (docs, pypi).

    Support de présentation : https://speakerdeck.com/xordoquy/packaging-pratique-fr

    Autres liens collectés

    • Pour travailler sur les docstrings d'un projet python, pyment peut être utile.
    • fedmsg est un bus de communication utilisé chez fedora/redhat pour un grand nombre d'applications, il y a probablement de bonnes choses dedans. Il y a un début de travail sur un bus similaire chez debian

    Prochain épisode

    Prochain épisode: jour 2


  • PyconFR 2014 : jour 1, frameworks web et gestion de source

    2014/11/04 by Arthur Lutz

    Suite de pyconfr 2014 jour 1 épisode 1.

    Performance des frameworks web : Python vs the world

    Ronan Amicel nous a présenté le travail de benchmark publié par TechEmpower. Ces tests et résultats sont forcement faux et biaisés, mais le code source des tests est publié en libre et il est donc possible d'apporter des corrections via le projet sur github

    Pour l'instant, Python3 serait plus lent que Python2, mais on peut espérer que Python3 rattrape son retard, puisqu'il est toujours développé. La comparaison avec pypy est surprenante, celui-ci est bien plus lent, l'hypothèse étant qu'il est ralenti lorsqu'il parle au driver mysql. En revanche, pour le test pypy + tornado, les performances peuvent être meilleures que nodejs car tornado est écrit en pur python il peut être optimisé par pypy.

    Dans le comparatif entre python et php, un acteur surprenant est phalcon qui a pris le parti de tout coder en C (plutôt qu'une partie seulement comme on peut le trouver dans nombre de projets python).

    Support de présentation : https://speakerdeck.com/ronnix/performance-des-frameworks-web-python-vs-the-world-v1-dot-1

    CubicWeb - Vos données ont du sens

    Nous attendions avec impatience cette présentation, et Christophe de Vienne a très bien présenté CubicWeb, le framework web dont Logilab est à l'origine.

    https://www.logilab.org/file/269991/raw/logo-cubicweb.png

    Après une courte introduction aux concepts du web sémantique (les URIS, les relations, le Linked Data), il a appuyé sur la nécéssité de donner du sens aux données que l'on stoque dans nos applications. Il a expliqué la finesse des réglages dans le moteur de permissions de CubicWeb.

    Il a expliqué certaines fonctionnalités intéressantes selon lui dans Cubicweb :

    • les hooks: équivalent des procédures stockées déclenchées par des triggers, ils sont écrits en Python et permettent de modifier des données en cascades, implémenter des règle de gestion ou générer des notifications.
    • les adaptateurs : permettent de maximiser la réutilisation de code en adaptant une entité à une nouvelle interface

    Selon Christophe, CubicWeb permet de développer une "base de donnée métier" strictement structurée, mais restant souple. Il a expliqué que l'interface par défaut n'est pas très sexy, mais qu'elle est néanmoins fonctionnelle comme backend d'édition.

    Une petite introduction aux cubes qui sont les "plugins" ou les "extensions" dans le monde CubicWeb, ils contiennent :

    • un schéma
    • du code métier
    • des vues
    • des contrôleurs

    Pour manipuler les données, CubicWeb utilise RQL, qui a été inventé avant SPARQL (langage de requête du web sémantique) et est plus pragmatique et lisible. Une fonctionnalité notable de RQL : plus besoin d'écrire des jointures SQL !

    Finalement Christophe a conclu en présentant le mariage de Pyramid et Cubicweb. Selon lui, en regardant dedans, ils ont des philosophies communes. Le code permettant de développer une application Pyramid sur une base CubicWeb est publié sur la forge de CubicWeb. Christophe a aussi expliqué qu'il pousse des modifications pour que CubicWeb soit plus accessible aux développeurs habitués aux modes de développement "à la python".

    Support de présentation : https://dl.dropboxusercontent.com/u/36590471/pyconfr-2014-pres-cubicweb/index.html

    La gestion de version, ce problème tellement simple…

    Pierre-Yves David (marmoute) nous a concocté un petit panorama des problèmes traités par les gestionnaires de source, avec des anecdotes de problèmes non-triviaux et quelques rappels historiques sur notre "science" informatique (merci les encodages!) Pierre-Yves s'est concentré sur les systèmes de gestion de version de "nouvelle génération", les outils décentralisés (hg, git, bzr). Forcément, étant donné qu'il travaille sur mercurial (et oui, celui écrit en python) il s'est concentré sur celui-là.

    http://mercurial.selenic.com/images/mercurial-logo.png

    Quand il travaillait chez Logilab, Pierre-Yves a notamment rajouté à Mercurial la notion de changeset obsolete et de phase pour faciliter la revue de code et le travail en équipe.

    Manipuler son code python avec RedBaron

    baron et RedBaron sont des projets assez prometteurs (et assez dingues) de manipulation de code en utilisant du code (plutôt que des éditeurs).

    Laurent Peuch est revenu sur les outils historiques du domaine : rope qui a pris la suite de bicycle repair man. Il y a aussi pyfmt par le même auteur, et autopep8 écrit par d'autres.

    Un exemple qui m'a parlé : ajouter @profile sur toutes les fonctions d'un script devient faisable en 3 lignes de python, et inversement pour les enlever. À suivre...

    Support de présentation : https://psycojoker.github.io/pyconfr-redbaron/presentation.html

    Prochain épisode

    Prochain épisode: jour 1, bus de communication, packaging et fin


  • PyconFR 2014 : jour 1, BDD, postgresql et asyncio

    2014/11/03 by Arthur Lutz

    J'ai eu le plaisir de participer à la conférence PyconFR 2014, voici quelques notes sur les présentations auxquelles j'ai pu assister. Étant donné la longueur, je vais publier sous forme de plusieurs billets de blog.

    http://www.pycon.fr/2014_static/pyconfr/images/banner.png

    BDD avec Behave

    Le Behaviour Driven Develpment en Python peut se faire avec behave. Dans un premier temps on décrit en language "naturel" le test. Dans un deuxième temps on implémente les tests unitaires pour faire le lien avec la description behave, et on met les chaines de caractères dans un decorateur @given, puis @when puis @then.

    Les scenarios behave sont utiles pour le dévelopement, pour la documentation, pour la formation des nouveaux arrivants et même pour faciliter la supervision des applications en production.

    Les diapos de la présentation sont disponible sur slideshare.

    Python + PostgreSQL

    Stéphane Wirtle nous a présenté comment les relations étroites entre le monde de Python et celui de PostgreSQL.

    https://avatars1.githubusercontent.com/u/2947270?v=2&s=400

    Points à noter :

    • FDW : Foreign Data Wrapper, dont voici une liste sur le wiki de PostgreSQL
    • PL (Procedure Language) : PL/C, PL/Python, PL/v8, etc. pour étendre sa base de donnée. Les procedure language SQL sont par défault "trusted", les autres ne sont pas trusted par défaut. Dans CubicWeb, nous utilisons PL/Python pour la recherche plein texte et la lemmatisation du texte.

    Pour ceux qui souhaiteraient essayer un ORM, Stéphane Wirtle conseille Peewee ORM.

    Pour les migrations de schema SQLalchemy, Stéphane Wirtle nous conseille Alembic.

    Parfois un ORM peut générer beaucoup de requêtes SQL et il y a de la place pour une optimisation en tapant directement du SQL. Pour évaluer la surcharge dûe à l'ORM, on peut utiliser pgBadger.

    Support de présentation : https://speakerdeck.com/matrixise/python-and-postgresql-a-wonderful-wedding/

    Un serveur fiable avec python 3.4

    Après une petite introduction aux principes de concurrence, Martin Richard nous a présenté un retour d'expérience sur l'utilisation du module asyncio introduit dans python 3.4. Il permet de ne plus avoir à utiliser twisted ou gevent.

    Les ressources et bibliothèques qui utilisent asyncio sont recensées sur http://asyncio.org/

    objgraph permet de d'analyser des structures de données Python pour identifier des fuites memoire.

    memoryview introduit dans python3.4 permet de faire "référence" à une structure de données sans la copier, ce qui peut être très pratique mais rend complexe la gestion de code.

    Martin a utilisé @lru_cache pour mettre en cache les resultats d'un calcul en utilisant la politique de cache "Least Recently Used (LRU)".

    Support de présentation : http://marti.us/t/pyconfr-2014/


  • PyconFR 2014 - on y va !

    2014/10/24 by Arthur Lutz

    Pycon.fr est l’événement annuel qui rassemble les utilisateurs et développeurs Python en France, c'est une conférence organisée par l'AFPY (L'Association Francophone Python). Elle se déroulera cette année sur 4 jours à Lyon : 2 jours de conférences, 2 jours de sprints.

    http://www.pycon.fr/2014_static/pyconfr/images/banner.png

    Nous serons présents à PyconFR les samedi et dimanche pour y voir les présentation nombreuses et prometteuses. Nous assisterons en particulier à deux présentations qui sont liés à l'activité de Logilab :

    On espère vous y croiser. Si tout va bien, nous prendrons le temps de faire un compte rendu de ce qui a retenu notre attention lors de la conférence.


  • Petit compte rendu du meetup postgresql d'octobre 2014

    2014/10/09 by Arthur Lutz

    Hier soir, je suis allé au Meetup PostgreSQL intitulé "DBA et Développeurs enfin réunis". Après quelques bières et pizza (c'est la tradition de le faire dans ce sens), nous avons écouté 4 présentations autour de PostgreSQL après une courte introduction de Dimitri Fontaine et des sponsors (Mozilla et Novapost).

    http://www.logilab.org/file/266939/raw/BzcR8UOIQAAdFMh.jpg

    Jean-Gérard Pailloncy nous a parlé d'aggrégation temporelle sous contrainte d'IOPS (page wikipedia pour IOPS, au cas où). Malgré le temps court de présentation, c'était une synthèse très bien déroulée d'un projet avec des flux de données ambitieux pour des plateformes "entrée de gamme". Quelques "petites" astuces que chacun pourrait appliquer à ses projets.

    Flavio Henrique Araque Gurgel nous a parlé du partitionnement de tables et des mythes qui entourent ce sujet. Dans quels cas dois-je partionner ? Beaucoup de cas de figure sont possibles, les métriques qui permettent de prendre ce genre de décisions sont nombreuses et nécessitent une bonne compréhension du fonctionnement interne des bases de données Postgresql. Il s'agissait principalement d'amener les praticiens de postgresql à se poser les bonnes questions lors de la conception de leur base de données.

    Thomas Reiss et Julien Rouhaud nous ont présenté POWA (PostgreSQL Workload Analyzer). Il s'agit d'une extension C pour postgresql (à partir de 9.3) et une interface en Perl and Mojolicious. Un projet prometteur (bien que l'on puisse être supris qu'il soit écrit en Perl) pour maîtriser les performances de sa base de données postgresql.

    http://www.logilab.org/file/266940/raw/safe.png

    Enfin, Dimitri Fontaine a prêché la bonne parole pour rapprocher les développeurs des administrateurs de bases de données. L'idée était de faire penser aux développeurs que le SQL dans leur code est du code, pas juste des chaînes de caractères. Quelques exemples autour des "window functions" et de "common table expressions" plus tard, on espère que les développeurs feront une partie de leurs calculs directement dans PostgreSQL plutôt que dans leur application (en évitant de balader des tonnes de données entre les deux). Petit conseil : il est recommandé de rajouter des commentaires dans les requêtes SQL. "SQL c'est un language de programmation en vrai."

    Les slides devraient être publiés sous peu sur le groupe meetup, que vous pouvez rejoindre pour être informés du prochain meetup. Update : slides publiés sur : https://wiki.postgresql.org/wiki/PostgreSQL_Meetup_Paris_2014_Sept

    À Logilab nous utilisons beaucoup Postgresql que ce soit sur des projets clients (données métier, GIS, etc.) mais aussi extensivement dans CubicWeb, framework web en python orienté web sémantique.

    Le format de 20 minutes par présentation est pas mal pour toucher rapidement à un grand nombre de sujets, du coup souvent il s'agit de pistes que chacun doit ensuite explorer. Les meetups sont toujours aussi sympathiques et accueillants.


show 67 results