Planète AFPy RSS

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

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

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

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

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

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

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

À bientôt !

[carlchenet] Tweet your database with db2twitter

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

[sciunto] Contributions #2

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

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

Associations

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

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

Archlinux

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

Scikit-image

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

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

Python

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

Divers

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

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

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

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

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

Les blogs ont-ils un avenir ?

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

 L'intérêt des planets

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

 Le relais ou la communication par les réseaux sociaux

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

Le journal du hacker

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

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

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

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

Vers un idéal ?

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

[tarek] Consistent Load Balancing

Publié le 2016-05-16 17:50:00

This is an interesting problem to look at. Let's say you have 1 million users and 5 storage servers. You are building an application that needs to pick one of the 5 storage servers depending on the user id.

You want your app to do it as consistently as possible. e.g. a given user should always land on the same backend.

When a request comes in:

  • each request is identified by a unique user id.
  • the app should always call the same storage server given that id.
  • you want all your users to be distributed equally across your storage servers.
  • when a storage server is removed from the list, you want users to stick with the servers they initially got. For users on the removed server, they should be dispatched equally on other servers.
  • when a server is added, you want the minimal numbers of users to be moved around.
  • The application is stateless about this, so when I deploy a new node and give it the list of the storage servers, it should be able to start distributing users among them without prior knowledge.

Point 4 and 6 discards a simple round-robin solution.

The solution to that problem is to build a deterministic function that projects a user id into the space composed of the servers. (yeah well, clustering I guess.)

There are two known algorithms to do that. The consistent hashing algorithm and the rendezvous hashing.

Consistent Hashing

Consistent Hashing is a hashing that can be used to minimize the shuffling of users when a server is removed or added.

This is how it's implemented:

  • each server name is converted into a unique number
  • that number is projected on an modulo interval (a circle)
  • every user is also converted into a unique number and projected on the circle
  • the server that's the closest to the user is picked

If you want nice drawing go here.

This is an elegant solution because removing a server keeps the rest stable, and adding one server shuffles a minimal number of users.

The conversion from a name to a integer is key here: you have to be deterministic but in the same time try to have the numbers randomly and kind-of-evenly distributed on the circle.

Here's how you can do it using MD5:

import hashlib

def hash(key):
    return long(hashlib.md5(key).hexdigest(), 16)

Using a classical hash like MD5 gives us the random part, but depending on the server name you might well end up with two servers that are very close to each other on the circle

And the result will be that when the users are converted into numbers, a very small amount of users will go to some servers.

One solution to fix that is to add replicas: for each server, instead of projecting a single number on the circle, we'll project 100. For example, "server1" becomes "server1:1", "server1:2", .., "server1:100" and those values are transformed into numbers.

Using replicas is very efficient to make sure users are spread evenly.

RendezVous

The other algorithm is called RendezVous and is based on a similar idea where servers are converted into numbers with a hash.

The difference is that instead of projecting servers and their replicas on a circle, the algorithm uses weights. To find which server a user should use, for each combination of server and user, a number is created with a classical hash function.

The server that's picked is the one with the highest number.

The Python code looks like this:

def get_server(user):
    high_score = -1
    winner = None

    for server in server:
        score = hash(server + user)
        if score > high_score:
            high_score, winner = score, ip
        elif score == high_score:
            high_score, winner = score, max(server, winner)

    return winner

The advantage of this method is that you don't have to create replicas to worry about distribution. In fact, according to my tests, RendezVous is doing a better job than Consistent Hashing for distributing users.

One key decision is to decide which hashing algorithm you want to use.

It's all about the hashing!

Both RendezVous and Consistent hashing are using a classical hashing function to convert the servers and users into numbers - and picking one was not obvious.

I came across this amazing stackexchange post that shed some light on different hashing, their strengths and weaknesses. You should read it, you will learn a lot.

The take away for my experiment was that some hashing functions are doing a better job at randomizing values in the hash space. Some very simple functions are also colliding quite often, which can be a problem.

So I tried a bunch of them and benchmarked them.

It's interesting to note that I had much better results for my use case using RendezVous & sha256 than RendezVous & Murmur, when the latter is usually what people use with RendezVous.

I ended up removing Murmur from my tests, the results where too bad.

Anyways, here's the full implementation I did, based on snippets I found here and there, and the result:

The gist

And the winnner is : RendezVous and sha256

Of course, that entirely depends on how many servers & users you have.

[sciunto] Grammalecte : sortie du greffon pour firefox

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

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

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

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

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

[anybox] Meteor 1.3 release

Publié le 2016-05-01 01:00:00

[anybox] La BDES au 1er janvier 2016

Publié le 2016-05-01 01:00:00

[anybox] Les 3 présentations de la première rencontre Elm à Paris

Publié le 2016-05-01 01:00:00

[anybox] À la découverte d'ERPNext

Publié le 2016-05-01 01:00:00

[anybox] We are Odoo professional service provider...

Publié le 2016-05-01 01:00:00
...but no more "Odoo S.A." partner, since the end of february. Here are the main reasons.

[anybox] Développement front-end en Javascript : les outils de base

Publié le 2016-05-01 01:00:00
Petit tutoriel pour comprendre rapidement les principaux outils de développement front-end en Javascript

[anybox] Configuration du serveur de mail Odoo avec Gmail

Publié le 2016-05-01 01:00:00

[anybox] Première présentation d'AnyBlok au PyConFR 2015 à Pau

Publié le 2016-05-01 01:00:00
Le 18 octobre 2015, Georges Racinet a présenté à Pau le framework AnyBlok.

[anybox] Vos applications métiers en Javascript avec Meteor

Publié le 2016-05-01 01:00:00

[anybox] An introduction to ERPNext module development

Publié le 2016-05-01 01:00:00

[anybox] La Base de Données Economiques et Sociales : pour qui, pourquoi et comment ?

Publié le 2016-05-01 01:00:00

[anybox] Dig into Elm

Publié le 2016-05-01 01:00:00

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

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

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

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

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

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

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

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

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

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

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

  • Séven Le Mesle (@slemesle) de

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

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

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

wescale

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

[afpyro] AFPYro à Nantes - mardi 20 avril

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

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

Vous pouvez nous informer de votre présence :

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

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

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

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

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

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

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

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

[sciunto] Ressources sur le libre

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

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

Actualités

 Conférences

 Sites de sensibilisation

Sites d'activité citoyenne

Miscellanées

Autres ?

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

[sciunto] NAS : choix des composants

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

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

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

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

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

Avantages/inconvénients d'un NAS

Avantages

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

Inconvénients

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

Choix technologiques

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

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

Les NAS commerciaux

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

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

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

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

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

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

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

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

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

Pour l'évolutivité :

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

Le choix

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

Le système d'exploitation

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

UPS

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

Carte mère

Les critères que j'ai retenu :

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

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

Version Quad core

Caractéristiques :

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

Version Octa core

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

RAM ECC

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

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

Chassis

Critères :

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

Mon choix :

Caractéristiques :

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

 Alim

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

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

USB

  • SanDisk Cruzer Fit 16 Go 6€

Avantages :

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

Disques

Je privilégie :

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

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

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

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

Connectique

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

SSD

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

Liens intéressants

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

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

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

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

On commence par installer jquery et mathjax

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

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

<VirtualHost *:80>

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

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

</VirtualHost>

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

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

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

par

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

pour le cas d'un appel http ou https ou

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

pour un appel en https seulement.

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

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

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

The mathematician prankster


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

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

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

Copying the prankster

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

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


Your assignment


Here is what I asked the students:

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

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

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

Learning more on Stan Ulam


See the wikipedia entry and also:

LOS ALAMOS SCIENCE NO. 15, 1987



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

Francois Dion
@f_dion

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

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

[ascendances] Des graphiques à la Xkcd

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

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

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

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

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

[tarek] Kinto Work Week Recap

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

We just had a work-week in London on Kinto our JSON storage project, and while heading back to France in the Eurostar, I figured I'd give a summary of where we're at in the project and what's next.

http://ziade.org/team-selfie.jpg

If you are not familiar with Kinto, it's an HTTP API that'll let you store (not so) arbitrary JSON content. Data is organized in collections, which are basically a list of timestamped records. As a client, you can query Kinto to get records filtered by dates or other fields. Kinto also provides neat features like a diff-based API to grab only the newest data, like how you would with a git client.

Kinto is the project designed to serve collections of data to Firefox in real-time, such as configurations.

Kinto stores arbitrary JSON because like some other storage systems, you don't really have to describe the data you are pushing in it like in a classical Database (you can if you want Kinto to control inputs).

Kinto stores not so arbitrary JSON because we're using some of the cool features Postgres has to index in specific fields the JSON mappings - and we are making the assumption that your data does follow a schema.

We were featured in Hackernews a couple of times already, and as you would expect, it sparked a lot of comparisons with other systems that exist. Things like "Are you the Parse killer?" "Why don't you use CouchDB already?" "You don't have everything Firebase provides!"

But frankly, for a HN thread, most of the feedback was really positive and useful for us. In particular it gave us a good hindsight on what things should be improved in the documentation. For instance, making it crystal clear that we are not building a product with a tight integration with the clients and the server API and a service we'd provide (our comparison table right now is a mixed bag of products and server-side frameworks, so that's confusing.)

We're building an HTTP API and we provide a JS client and working on some other clients -- that's it for now.

That said, we're sure hoping products and services will be built by the community with this "toolkit" at some point in the future.

But as far as 2016 is concerned, our main goal is to develop Kinto for our needs in Firefox.

Kinto & Firefox

For our daily work, the goal of Kinto is to be used in Firefox as the go-to service to grab data continuously from our servers without having to wait for the next release.

That's the Go Faster umbrella project.

We're going to use Kinto for:

  • the OneCRL client in Firefox, that is syncing the list of certificate revocations in Firefox. The plan is to offer the security team the ability to deploy a change to all our users as fast as possible.
  • the AMO blocklist client in Firefox, to get an up-to-date list of add-ons that should be blocked.
  • Fennec Assets : static files needed by Fennec (Firefox for Android), like font files, hypenation dictionaries and so on. The goal here is to reduce the APK file size as much as possible and to limit the amount of data exchanged between mobile phones and our servers as well.

OneCRL

Mark is driving the development of the client on behalf of the Firefox Security Team, and besides the obvious benefit of getting certificate revocations changes on-the-fly as diffs, he started to work with my team, Julien and Franziskus on a signing protocol that will allow the Kinto client to verify that the data that was sent by the server was not tampered with.

That work started a few months ago and the work week was a perfect time to give it a boost.

On the server-side, the signing is done with a micro-service Julien started, called autograph that will let a Kinto administrator sign the data before it's pushed into Kinto.

See https://github.com/mozilla-services/autograph

Kinto is interacting with the signer through a specialized plugin, that triggers the signing whenever some data is changed into Kinto, and that makes sure the data is published to clients once properly signed.

See https://github.com/mozilla-services/kinto-signer

The storage itself is pretty passive about this, as it just stores signed hashes of collections and let any client get them back.

The Kinto client can grab that signature and ask Firefox to verify it before applying data changes. The verification logic uses a custom PKI that Mark and Franziskus and building on top of NSS in the client.

Obviously, we should do this for all the data Kinto ever sends to Firefox, so going forward, all our Kinto deployments will integrate by default signatures capabilities.

http://ziade.org/kinto-ww.jpg

AMO Blocklist

The existing AMO blocklist client is already doing most of what we do in Kinto: it performs daily download of an XML file and applies changes in Firefox.

So what are the benefits of moving to Kinto for this ?

The biggest one will be the signing of the data, since this is not something the current client has. The second one will be to separate the feature from the current AMO Django website. Instead of having a dashboard within the Django admin to push data, the Addons administrator will be able to manage the whole dataset in a dedicated web admin.

We've built an admin app for Kinto that will be used for this.

See https://github.com/Kinto/kinto-admin

It's a static React-based app, and we're providing now a Kinto Distribution to let you have a full Kinto service that include among other things that web admin hooked into an /admin endpoint.

See https://github.com/Kinto/kinto-dist/

The last benefit is mostly a side-benefit, but quite important. Right now, the daily ping done by Firefox for the AMO blocklist is used for some metrics work. This is not related to the blocklist feature itself, but happened for historical reasons.

The plan (ongoing dicussion though) is to separate the two features in Firefox as they should, and make sure we have a dedicated ping mechanism for the metrics.

We'll end up with two clearly separated and identified features, that can be maintained and evolve separately.

Fennec Assets

Sebastian, from the Fennec team, has been working on the Fennec client to sync a list of assets into Kinto. The goal is to reduce the size of the Android package, and download those extra files in the background.

We've built for this a plugin to Kinto, to extend our API so files could be uploaded and downloaded.

Kinto stores files on disk or on Amazon S3 (or whatever backend you write the class for) and their metadata in a Kinto collection.

See https://github.com/Kinto/kinto-attachment/

From a client point of view, what you get is a MANIFEST you can browse and sync locally, of what files are available on the server.

Fennec is going to use this to let admins manage static file lists that will be made available to the mobile browser, and downloaded if they really need them.

Next Steps

They are tons and tons of other stuff happening in Kinto right now, but I wanted to give you an overview of the three major use cases we currently have for it at Mozilla.

If all goes according to ours plans, these are the Firefox versions they will land in:

  • OneCRL: Firefox 47 - June 7th
  • Fennec: Firefox 48 - July 18th
  • AMO: Firefox 49 - August 8th

Good times!

[sciunto] Contributions #1

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

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

Archlinux

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

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

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

Jirafeau

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

Scikit-image

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

Scipy

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

Ikiwiki-pandoc

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

Gitbackup

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

Python-bibtexparser

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

share.sciunto.org

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

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

Quartzy : fermeture d'un service SaaS

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

[cubicweb] Moving forward on CubicWeb development

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

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

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

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

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

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

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

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

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

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

A glance at JSON API

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

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

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

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

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

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

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

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

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

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

CRUD

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

For instance, creating a ticket could be done as:

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

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

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

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

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

Relationships

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

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

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

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

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

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

Related resources

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

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

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

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

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

Meta information

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

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

Permissions

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

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

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

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

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

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

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

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

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

More Hypermedia controls

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

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

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

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

Request for comments

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

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

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

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

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

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

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

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

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

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

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

Problématique

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

Principe

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

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

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

# On pousse
git push --mirror

A intervalle régulier, on peut faire

git fetch -p origin
git push --mirror

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

gitbackup

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

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

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

# On initialise
gitbackup init

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

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

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

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

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

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

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

[cubicweb] Towards building a JavaScript user interface to CubicWeb

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

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

As of today, three main topics have been identified:

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

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

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

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

Feedback welcome!

[cubicweb] Happy New Year CubicWeb !

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

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

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

CubicWeb 3.21

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

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

CubicWeb 3.22

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

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

Roadmap and bi-monthly meetings

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

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

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

[sciunto] Don du mois : debian

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

Ce post s'inscrit dans la série des dons pour vous donner envie de contribuer même très modestement à des logiciels libres. Les petites pierres font les grands édifices.

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

Pour faire un don à debian

[carlchenet] Le danger Github

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

[tarek] A Pelican web editor

Publié le 2016-01-21 09:40:00

The benefit of being a father again (Freya my 3rd child, was born last week) is that while on paternity leave & between two baby bottles, I can hack on fun stuff.

A few months ago, I've built for my running club a Pelican-based website, check it out at : http://acr-dijon.org. Nothing's special about it, except that I am not the one feeding it. The content is added by people from the club that have zero knowledge about softwares, let alone stuff like vim or command line tools.

I set up a github-based flow for them, where they add content through the github UI and its minimal reStructuredText preview feature - and then a few of my crons update the website on the server I host. For images and other media, they are uploading them via FTP using FireSSH in Firefox.

For the comments, I've switched from Disqus to ISSO after I got annoyed by the fact that it was impossible to display a simple Disqus UI for people to comment without having to log in.

I had to make my club friends go through a minimal reStructuredText syntax training, and things are more of less working now.

The system has a few caveats though:

  • it's dependent on Github. I'd rather have everything hosted on my server.
  • the github restTRucturedText preview will not display syntax errors and warnings and very often, articles get broken
  • the resulting reST is ugly, and it's a bit hard to force my editors to be stricter about details like empty lines, not using tabs etc.
  • adding folders or organizing articles from Github is a pain
  • editing the metadata tags is prone to many mistakes

So I've decided to build my own web editing tool with the following features:

  • resTructuredText cleanup
  • content browsing
  • resTructuredText web editor with live preview that shows warnings & errors
  • a little bit of wsgi glue and a few forms to create articles without having to worry about metadata syntax.

resTructuredText cleanup

The first step was to build a reStructuredText parser that would read some reStructuredText and render it back into a cleaner version.

We've imported almost 2000 articles in Pelican from the old blog, so I had a lot of samples to make my parser work well.

I first tried rst2rst but that parser was built for a very specific use case (text wrapping) and was incomplete. It was not parsing all of the reStructuredText syntax.

Inspired by it, I wrote my own little parser using docutils.

Understanding docutils is not a small task. This project is very powerfull but quite complex. One thing that cruelly misses in docutils parser tools is the ability to get the source text from any node, including its children, so you can render back the same source.

That's roughly what I had to add in my code. It's ugly but it does the job: it will parse rst files and render the same content, minus all the extraneous empty lines, spaces, tabs etc.

Content browsing

Content browsing is pretty straightforward: my admin tool let you browse the Pelican content directory and lists all articles, organized by categories.

In our case, each category has a top directory in content. The browser parses the articles using my parser and displays paginated lists.

I had to add a cache system for the parser, because one of the directory contains over 1000 articles -- and browsing was kind of slow :)

http://ziade.org/henet-browsing.png

resTructuredText web editor

The last big bit was the live editor. I've stumbled on a neat little tool called rsted, that provides a live preview of the reStructuredText as you are typing it. And it includes warnings !

Check it out: http://rst.ninjs.org/

I've stripped it and kept what I needed, and included it in my app.

http://ziade.org/henet.png

I am quite happy with the result so far. I need to add real tests and a bit of documentation, and I will start to train my club friends on it.

The next features I'd like to add are:

  • comments management, to replace Isso (working on it now)
  • smart Pelican builds. e.g. if a comment is added I don't want to rebuild the whole blog (~1500 articles)
  • media management
  • spell checker

The project lives here: https://github.com/AcrDijon/henet

I am not going to release it, but if someone finds it useful, I could.

It's built with Bottle & Bootstrap as well.

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

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

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

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

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

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

Salt Meetup

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

Salt + Graphite + Grafana

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

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

Saltpad screenshot

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

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

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

La suite : un meetup en février ?

[sciunto] Profilage CPU de rss2email et feedparser (python)

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

J'ai déjà parlé à plusieurs reprises sur ce blog de rss2email pour récupérer les flux rss. Avec plus d'une centaine de flux, il est un peu lent et consomme tout de même pas mal de CPU. Je me suis donc lancé dans un profilage du code pour comprendre ce qui consommait le plus.

Deux objectifs à ce billet :

  • rapporter ma méthode
  • demander à la communauté ce qu'on peut faire pour optimiser ce que j'ai identifié (cf la fin de ce billet)

Mise en place du profilage

On commence par cloner le dépôt de rss2email

git clone https://github.com/wking/rss2email
cd rss2email

ainsi que feedparser, la bibliothèque principale car je pressens qu'on va devoir y jeter un coup d'oeil.

git clone https://github.com/kurtmckee/feedparser.git

Je crée un virtualenv avec pew, comme suggéré par sametmax, c'est bien plus pratique.

pew new profiler

Construction et déploiement du code avec la méthode develop. Elle fait un lien symbolique, ce qui permet de ne pas avoir à faire une installation à chaque modification de code, ce qui est très intéressant lorsqu'on avance à petit pas dans le profilage.

cd feedparser
python setup.py develop
cd ..
# rss2email
python setup.py develop

On vérifie que ça tourne comme on l'attend. J'ai importé mes fichiers de conf et de base de données du serveur de prod pour être en condition de données réelles. L'option -n permet de faire un dry-run, c'est-à-dire de ne pas envoyer le courriel.

r2e -c rss2email.cfg  run 30 -n

J'installe la bibliothèque qui permet de profiler le CPU. Voir cette référence que j'ai trouvé utile pour les différentes méthodes de profilage en python.

pip install line_profiler

Pour activer le profilage sur une fonction, il suffit d'utiliser un décorateur.

@profile
def func(var):
    ...

On lance ensuite kernprof

kernprof -l -v r2e -c rss2email.cfg  run 30 -n

De manière récursive, je descend dans le code en répérant les fonctions qui prennent le plus de temps CPU.

Résultats

Le résultat est que le temps CPU est principalement utilisé par feedparser, que la moitié du temps sert à récupérer des données à travers le réseau (urllib) et l'autre moitié à faire du parsage de date. Ce parsage est traité en interne par feedparser.

Ces résultats sont rapportés dans ce ticket.

Regardons plus en détails. Il existe plusieurs formats à gérer. Pour mes flux, c'est principalement rfc822.

Le code commence par ceci

timezonenames = {
    'ut': 0, 'gmt': 0, 'z': 0,
    'adt': -3, 'ast': -4, 'at': -4,
    'edt': -4, 'est': -5, 'et': -5,
    'cdt': -5, 'cst': -6, 'ct': -6,
    'mdt': -6, 'mst': -7, 'mt': -7,
    'pdt': -7, 'pst': -8, 'pt': -8,
    'a': -1, 'n': 1,
    'm': -12, 'y': 12,
    'met': 1, 'mest': 2,
}

def _parse_date_rfc822(date):
    """Parse RFC 822 dates and times
    http://tools.ietf.org/html/rfc822#section-5
    There are some formatting differences that are accounted for:
    1. Years may be two or four digits.
    2. The month and day can be swapped.
    3. Additional timezone names are supported.
    4. A default time and timezone are assumed if only a date is present.
    """

    daynames = set(['mon', 'tue', 'wed', 'thu', 'fri', 'sat', 'sun'])
    months = {
        'jan': 1, 'feb': 2, 'mar': 3, 'apr': 4, 'may': 5, 'jun': 6,
        'jul': 7, 'aug': 8, 'sep': 9, 'oct': 10, 'nov': 11, 'dec': 12,
    }

    parts = date.lower().split()

Avec le profilage, j'ai vu que 10% du temps était utilisé à construire le set(). Les avantages de set sont de garantir l'unicité et d'avoir des opérations de type union ou intersection (comme le dit la doc). Ici, daynames n'est pas modifié, on n'a pas donc besoin de fabriquer l'unicité sur quelque chose qu'on définit. Seule une itération est faite sur cet élément. Le set() ne me semble donc pas justifié.

J'ai ouvert un pull request pour corriger le set en tuple, et passer la déclaration en variable globale.

Si vous avez des suggestions pour améliorer les performances, n'hésitez pas à les partager sur github ou par email. Merci !

Note : email.utils.parsedate_tz semble être plus lent que l'implémentation de feedparser, en terme CPU, c'est relativement comparable.

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

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

[carlchenet] Étendre votre réseau Twitter avec Retweet 0.8

Publié le 2016-01-12 23:00:21
Pour rappel si vous n’avez pas lu mes précédents billets sur le sujet,  Retweet est une application  permettant de retweeter tous ou certains statuts d’un compte du réseau social  Twitter vers un autre compte. Retweet est codé en Python 3 et sous licence GPLv3. Le Github de Retweet (étoiles appréciées 😉 ) Documentation officielle de… Continuer de lire Étendre votre réseau Twitter avec Retweet 0.8

[carlchenet] Extend your Twitter network with Retweet

Publié le 2016-01-11 23:00:28
Retweet is self-hosted app coded in Python 3 allowing to retweet all the statuses from a given Twitter account to another one. Lots of filters can be used to retweet only tweets matching given criterias. Retweet on Github (stars appreciated if you like it/use it ) Retweet official documentation Retweet 0.8 is available on the… Continuer de lire Extend your Twitter network with Retweet

[sciunto] Grammalecte : avancement

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

Au printemps dernier avait été lancé une campagne de financement pour grammalecte, un correcteur grammatical et typographique dont la teneur est expliquée notamment sur linuxfr. J'ai cherché à voir l'évolution du projet puisque la campagne s'est terminée avec succès. J'ai pu trouver l'état d'avancement sur le forum.

Malheureusement, il semble que l'auteur n'utilise pas de forge. D'après mes recherches, la dernière beta est la 0.5.0b4, sous forme d'extension pour libreoffice. L'ordre prévu par la campagne fait que le développeur doit se consacrer en premier à l'extension firefox, dont une version est prévue avec la sortie de firefox 44, pour des questions de version de javascript.

Néanmoins, en ouvrant l'extension pour libreoffice, on a accès au parser écrit en python. L'extension étant installée pour moi, je retrouve ce fichier dans

python $HOME/.config/libreoffice/4/user/uno_packages/cache/uno_packages/luq78j49.tmp_/Grammalecte-v0.5.0b4-1.oxt/pythonpath/parser.py

J'en ai fait un alias qui s'appelle grammalecte. Trois commandes sont possibles :

  • grammalecte : permet de tester le texte que vous entrez à la main.
  • grammalecte -f filename : pour analyser un fichier texte (UTF-8 requis).
  • grammalecte -ff filename : pour analyser un fichier texte (UTF-8 requis) et produire un fichier résultat.

Le résultat est plutôt bon, on peut clairement aller chercher les erreurs dans un fichiers markdown ou latex. Il y aura cependant des erreurs soulevées pour les balises ainsi que, dans mon cas, les apostrophes typographiques puisque je n'utilise que des apostrophes droites. Je n'ai pas vu de moyen pour ne pas faire apparaitre certaines erreurs. Celle des apostrophes est particulièrement handicapante dans mon cas, c'est à dire la différence entre l'apostrophe et l’apostrophe.

Mais c'est là que vient l'option -tf, qui corrige la typographie avant de regarder la grammaire. Ainsi, il suffit de faire

grammalecte -tf -f filename

En somme, il y a déjà de quoi avoir un outil fonctionnel même si une version finale n'est pas encore sortie.