Pecosys est le projet évoqué dans mon dernier billet pour gérer des commentaires avec un blog statique créé avec Pelican. J'ai publié l'ensemble des sources sur mon GitHub sous licence GPL. Avant d'expliquer à quoi ça sert, une présentation des types de moteurs de blog s'impose.

Petite intro sur les blog statiques

Les moteurs de blog classiques comme Wordpress ou Dotclear stockent leurs données (articles, commentaires) dans une base de données et ils utilisent une logique côté serveur pour produire les pages HTML. Au fil des ans, ces moteurs ont rajouté beaucoup de fonctionnalités (par l'utilisation de plugins) et on les appelle désormais des CMS (Content Management System) car ils peuvent servir à bâtir tout type de site Web, en facilitant le travail de publication et de collaboration aux rédacteurs qui n'ont plus besoin d'être des gens techniques.

PluXml est un moteur un peu à part, plus léger que les CMS cités ci-dessus, qui n'utilise pas de base de données mais stocke les données dans des fichiers XML. C'est un pas dans la direction des blogs statiques dans la mesure où cela permet de mettre son blog dans un gestionnaire de sources (comme GIT) et conserver une traçabilité des changements. Cela facilite aussi la migration du blog.

Pelican et Jekyll sont des vrais blogs statiques. Ils n'utilisent pas de langage serveur comme PHP ou Ruby, il ne stockent pas leurs données dans une base de données. Les articles sont écrits dans un langage Markup comme Markdown et la construction du site (le build) est réalisé hors ligne. Il génère les pages à base de HTML, CSS et éventuellement un zeste de JavaScript. Ces pages sont transférées vers le serveur HTTP hébergeant le site... et hop le site est à jour.

Alors pourquoi s'embêter à gérer un site statique alors qu'un Wordpress s'installe en 5 minutes ?

Cela dépend de tout un chacun mais j'y suis venu pour les raisons suivantes :

• Les articles sont écrits dans un format simpliste (pour ma part c'est Markdown), la présentation est clairement séparée du contenu. C'est lors du build qu'on génère le code HTML en fonction de templates et de CSS personnalisés par nos soins. Le code HTML généré par Pelican est propre et léger. Le jour où j'ai migré de WordPress à PluXml, j'ai été horrifié par le code HTML de WordPress.
• Le contenu du blog est un ensemble de fichier au format texte, idéal à gérer avec un gestionnaire de sources afin de garder trace des modifications. Un gestionnaire de sources devient aussi un moyen d'automatiser la mise à jour du site. On écrit et on teste sur sa machine de dev, on publie sous GIT et il suffit que le serveur rafraîchisse sa version du site quand une modification a été effectuée.

La problématique des commentaires

Pas de logique serveur, juste un ensemble de pages HTML avec un peu d'interactivité grâce à JavaScript. Comment gérer les commentaires avec un site statique ? La solution proposée par Pelican c'est l'utilisation des services de la société Disqus. Un peu de JavaScript embarqué au bon endroit et vos pages sont agrémentées d'un formulaire pour poster des commentaires qui envoie les données chez Disqus et l'affichage de la page dans le navigateur client par l'usage de JavaScript, envoie des requêtes à Disqus pour rapatrier les commentaires approuvées et les ajouter à la page HTML qui vient de votre serveur.

Est-ce que vous sentez venir l'objection ?

D'abord on met en place une belle mécanique,très pure, où l'on contrôle le contenu, l'affichage, puis on confie la partie sensible (les données utilisateur) à une société commerciale, qui ne demande rien en retour et qui propose sûrement un service aux petits oignons pour approuver les commentaires... mais qui garde les données. Comment une société comme Disqus monétise ses services ? Je ne sais pas, peu importe. Que se passe-t-il si la société dépose le bilan ? Là j'ai la réponse. L'ensemble des commentaires est perdu : une bonne partie de la richesse d'un blog, ce qui fait son histoire. Dommage non ?

L'approche Pecosys

Pecosys est un serveur de commentaires écrit en Python que vous hébergez sur le même serveur que votre blog. Il reçoit les commentaires à approuver depuis le blog par le biais d'un formulaire sur le blog. Pour cela, les templates de Pelican ont été adaptés afin de rajouter ce formulaire en bas de chaque article.

Le lien entre le blog statique et le serveur Pecosys est réalisé par grâce au serveur Web. Dans le cas de NginX, il est trivial d'associer une URL à un programme Python. Dans le cas d'Apache, c'est faisable facilement en utilisant le module Proxy. Bref, le serveur Pecosys est d'abord un serveur HTTP sur lequel on poste les commentaires entrés par un formulaire classique de création de commentaires.

Quand un commentaire est reçu, le serveur va faire deux trucs : sauvegarder le commentaire et le soumettre à l'administrateur du blog.

La sauvegarde se fait grâce à GIT. Ah j'avais pas encore parlé de GIT :-) On suppose qu'on est dans une architecture centralisée où le blog est modifié depuis une machine de développeur et poussé (au sens GIT: PUSH) vers un bare repository. Dans mon cas, cette référence centrale des sources est sous BitBucket car ils acceptent la création de dépôts privés gratuitement et que je ne veux pas publier les adresses emails de tous ceux qui ont laissé un commentaire sur le blog. Souvenez-vous les commentaires font désormais partie des sources du blog, on verra comment plus loin.

Donc, pour résumer :

• j'écris mes articles sur ma machine de dev perso, je publie dans GIT et je pousse mes modifications au GIT centralisé de BitBucket (au sens GIT: ORIGIN).
• mon serveur vérifie périodiquement si le dépôt BitBucket a été modifié et si c'est le cas, il rapatrie les sources du blog et reconstruit le site grâce à sa mécanique Pelican installée localement.
• Pecosys a sa propre version du blog (au sens GIT: CLONE) maintenue à jour de BitBucket.

Donc quand Pecosys reçoit un nouveau commentaire, il met à jour sa version du blog (la branche MASTER) et il crée une nouvelle branche XYZ pour ce commentaire. il sauve ce commentaire dans les sources du blog (au format Markdown) et il committe la branche XYZ.

Ensuite, le serveur va le communiquer à l'administrateur du blog par email. Cela suppose qu'un email dédié est utilisé par Pecosys (pourquoi pas blog@mydomain.com) et qu'il connaît l'email de l'administrateur du blog (vous !). Cet email contient le commentaire et demande une réponse.

L'administrateur du blog (toujours vous) doit répondre à cet email. Une réponse sans commentaire revient à approuver le commentaire et va lancer sa publication. Une réponse avec un commentaire "NO" (désolé pour l'originalité) signifie qu'on refuse le commentaire.

En fonction de cette réponse, le serveur Pecosys qui vérifie sa boite de réception régulièrement, va traiter le commentaire :

• un refus du commentaire revient à supprimer la branche GIT XYZ
• une approbation du commentaire ramène les modifications de la branche XYZ sur la branche MASTER (au sens GIT: MERGE) et pousse les modifications sur le GIT distant (dans mon cas BitBucket)

Dans les deux cas, un email de confirmation de l'action réalisée est envoyé à l'administrateur du blog.

A ce stade, la branche de référence BitBucket est à jour donc le serveur va ramener ses modifications, reconstruire le site et par là même publier le commentaire.

Si vous avez bien suivi et je sais que c'est un peu touffu et compliqué, vous vous demandez comment les commentaires (ces fichiers en Markdown) sont générés en HTML. Et bien, pas le biais d'un plugin Pelican nommé CaCause, en hommage au projet de base initié il y a un an avec Bruno Adele et Nahir Mohamed dont Pecosys est une reprise des idées principales mais avec une réalisation différente par son dialogue basé sur l'email et son utilisation forcenée de GIT.

Je teste Pecosys depuis deux semaines sur ce site et je suis prêt à donner un coup de main à quiconque veut se lancer. Sur GitHub, j'ai publié les sources du serveur mais aussi une version allégée de ce site (sans les commentaires) qui contient donc mes templates avec le formulaire et les sources du plugin.

En attendant je retourne à mon farniente estival :-)

Original post of Yannic Arnoux.Votez pour ce billet sur Planet Libre.

Je vous parlais il y a déjà plus de 6 mois des bases de données chronologiques, ces bases spécialisées dans la gestion des données de type chronologiques, parfaites donc pour accueillir les données de métrologie.

Et bien c’est InfluxDB que j’ai choisi pour succéder petit à petit à Graphite sur mon environnement de supervision. InfluxDB en est déjà à sa version 0.8 au moment d’écrire ces lignes. Le projet avance vite, possède de nombreux contributeurs et toutes les armes aujourd’hui pour envisager de l’utiliser en lieu et place de Graphite.

Décidément, le monde de l’Open Source est impitoyable. À peine avez-vous élu une brique qu’une nouvelle prétend pouvoir prendre la place. Vérifions tout cela dans un setup classique sur Wooster; à savoir Collectd envoie ses données dans InfluxDB donc et Grafana nous visualise toutes ces jolies métriques.

Installation et configuration de InfluxDB

Rien à dire, un .deb à installer sur ma Ubuntu habituelle et basta ! C’est plus simple que l’installation en environnement virtuel de Graphite, pas de doute là-dessus.

Côté configuration, je n’ai rien fait. Je note au passage un plugin qui permet de faire passer InfluxDB pour un serveur Graphite sur le réseau. Il faudra que je teste même si pour l’instant, je vais à l’essentiel.

Une petite vérification via l’interface d’administration fournie que le serveur est bien démarré et prêt. Il suffit de se connecter sur http://localhost:8083 et de fournir root et root pour s’identifier.

Création d’une base de données

Toujours via cette interface web d’administration, je créé une base de données appelée collectd, allez savoir pourquoi ! J’y affecte un utilisateur collectd avec le mot de passe collectd.

git clone https://github.com/hoonmin/influxdb-collectd-proxy
cd influxdb-collectd-proxy
sudo apt-get install golang-go
make

bin/proxy --typesdb="types.db" --database="collectd" --username="collectd" --password="collectd"

Usage of bin/proxy:
  -database="": database for influxdb
  -influxdb="localhost:8086": host:port for influxdb
  -logfile="": path to log file (log to stderr if empty)
  -normalize=true: true if you need to normalize data for COUNTER and DERIVE types (over time)
  -password="root": password for influxdb
  -proxyhost="0.0.0.0": host for proxy
  -proxyport="8096": port for proxy
  -typesdb="types.db": path to Collectd's types.db
  -username="root": username for influxdb
  -verbose=false: true if you need to trace the requests

LoadPlugin network


  # proxy address
  Server "127.0.0.1" "8096"

Vérification de la base de données

Avant d’essayer de grapher nos données Collectd, il est plus prudent de vérifier que les données arrivent bien dans InfluxDB. Il est bien sûr toujours possible d’utiliser la consolde web d’administration pour cela.

Une requête comme celle-ci select * from /.*/ limit 10 permet de voir les dix derniers enregistrements stockés pour chaque métrique remontée par Collectd. Vous avez dit SQL ?

Premier graphe avec Grafana

Puisque tout fonctionne correctement, reste à grapher ces données dans Grafana et ainsi constituer de jolis tableaux de bord.

Configuration de Grafana pour InfluxDB

Le fichier de configuration de Grafana, config.js, gère la notion de datasources.

    datasources: {
      graphite: {
        type: 'graphite',
        url: "http://localhost",
        default: true
      },
      influxdb: {
        type: 'influxdb',
        url: "http://localhost:8086/db/collectd",
        username: 'collectd',
        password: 'collectd'
      },
    },

Rien d’extraordinaire et c’est tant mieux ! J’ai volontairement laissé le datasource Graphite, souhaitant faire fonctionner les deux systèmes en parallèle pour un certain temps.

Métriques de charge système dans Grafana

Quoi de mieux que cett bonne vieille métrique de load pour un premier test.

Rien de bien différent par rapport à un graphe Graphite. Il faut juste penser à sélectionner InfluxDB comme source des métriques graphées. J’ai apprécié la possibilité de renommer chaque métrique et d’éviter ainsi les noms à rallonge de type hyp-001.load.load-shortterm.

Original post of Wooster by CheckmyWebsite.Votez pour ce billet sur Planet Libre.

Cet article fait suite à une première que vous pourrez lire sur notre site.

Partie 1 - Hello World :
http://www.elementaryos-fr.org/bonjour-monde-vala/

Dans cette deuxième partie, nous allons voir comment gérer les éventuelles erreurs générées par votre code.

Prenons ce code :

public static void main (string[] args) {
 string contents;
 FileUtils.get_contents ("/uri/to/path.txt", out contents);
}

si le chemin '/uri/to/path.txt' n'existe pas, vous aurez cette erreur :

** (process:29257): CRITICAL **: file main.vala.c: line 27: uncaught error: Failed to open file '/uri/to/path.txt': No such file or directory (g-file-error-quark, 4)

pour palier ce problème, il faudra "attraper" cette erreur. Pour cela on utilise les mots-clé "try" et "catch" :

public static void main (string[] args) {
 string contents;
 try {
  FileUtils.get_contents ("/uri/to/path.txt", out contents);
 } catch {
  print ("une erreur s'est produite !\\n");
 }
}

Le soucis est que si vous souhaiter avoir l'information de l'erreur vue plus haut, vous devez capturer un type d'erreur spécifique. la fonction FileUtils.get_contents lance une erreur de type GLib.FileError. On indique donc à "catch" ce type :

public static void main (string[] args) {
 string contents;
 try {
  FileUtils.get_contents ("/uri/to/path.txt", out contents);
 } catch (FileError fe) {
  print (fe.message + "\\n");
 }
}

Il se peut que plus tard dans vos codes, il  y est à gérer différents types d'erreurs. Dans ce cas il faut capturer le type commun à toutes ces erreurs "GLib.Error".

Il se peut aussi que vous vouliez lancer une erreur dans votre code à un moment. Pour cela il faut utiliser la fonction 

error ("texte de l'erreur");

La troisième partie sera consacrée à la création de classes.

Le billet Gestion des erreurs dans votre code a été publié sur elementary OS Fr - Communauté francophone d'elementaryOS

Original post of elementary OS.Votez pour ce billet sur Planet Libre.

Petite nouveauté sur le site elementaryos-fr.org, nous inaugurons une série d'articles liés à la programmation, plus particulièrement au langage vala qui est utilisé sur votre OS favori elementary OS.. C'est breizhodrome, nouvel arrivé dans l'équipe qui s'occupera de ces articles.

Avant de rentrer dans le vif du sujet, et pour ceux qui ne connaissent pas Vala, voici une courte introduction issue de Wikipedia.fr :

Vala est un langage de programmation compilé, dont l'objectif est de fournir les bénéfices des langages de programmation modernes (comme la POO) aux développeurs de la plateforme GNOME qui utilisent GLib et son système GObject.

Sa syntaxe est basée sur celle de C# mais il ne nécessite pas d'environnement d'exécution. Vala est transformé en code C, lui-même compilé en code machine natif. Les avantages d'une telle chaîne de compilation sont de produire des logiciels qui requièrent moins de mémoire vive et qui s'exécutent plus rapidement.

De plus, ce passage par l'étape C rend possible l'utilisation des bibliothèques C au moyen d'interfaces définies dans les fichiers Vapi. Des fichiers Vapi sont fournis avec Vala pour une grande partie de la plateforme GNOME, ainsi que pour d'autres bibliothèques.

Par exemple, le logiciel Shotwell, GNOME Contacts1 ou le greffon Arte+7 pour Totem2 sont écrits en Vala.

Néanmoins, avant de se lancer dans la compilation de programme Vala, il est important d'installer un compilateur en l'occurence valac. Pour cela, il faudra passer par votre terminal favori :

sudo apt-get install valac-0.22

Une fois cette courte étape réalisée, c'est parti pour les explications, bonne lecture !

Tout d'abord, qu'est ce que le langage Vala ? Si vous ne le savez pas encore c'est la base de la plupart des applications d'elementary OS. Sa syntaxe est proche du C#.
Valac, son compilateur, traduit tout d'abord votre code en langage C, interprétable par le compilateur gcc qui le traduira en binaire (01) pour la machine.
Tout programme Vala se doit d'avoir une fonction principale d'entrée "main", qui peut s'écrire sous plusieurs formes :

public static void main() {}
public static int main() { return 0; }
public static void main (string[] args) {}

par exemple :

static void main (string[] args) {
  print ("bonjour tout le monde !");
}

Pourquoi le paramètre 'args' ? ça permet à votre programme d'utiliser des arguments lors de son exécution. le premier élément étant le nom de programme, et les éventuels autres valeurs entrées dans votre terminal. Enregistrez ce code dans un fichier nommé "main.vala" :

static void main (string[] args) {
  if (args.length < 2) {
    print ("usage: main \\n");
    return;
  }
  print ("argument : " + args[1] + "\\n");
}

que vous compilerez par : 

valac main.vala -o main

./main toto

Le résultat sera "argument : toto"

Voilà, vous avez réussi à écrire votre premier programme vala :).
Dans un prochain article vous verrez la gestion des erreurs dans votre programme.

Le billet Bonjour le monde Vala ! a été publié sur elementary OS Fr - Communauté francophone d'elementaryOS

Original post of elementary OS.Votez pour ce billet sur Planet Libre.

Si vous aimez bien tester des applications originales, Limoo est une visionneuse d’images qui peut vous plaire par son côté léger et minimaliste. Je ne sais pas grand-chose sur cette application, si ce n’est qu’elle est open source, écrite en C++ et qu’elle dispose d’une interface graphique basée sur Qt5 et QML. Au niveau des fonctions elles sont assez limitées, car Limoo est comme le titre l’indique une visionneuse et non pas un gestionnaire d’images. Là ou Limoo se démarque des autres solutions de ce type en revanche, c’est par son interface qui vous allez le voir, est assez spéciale.

Sur la capture ci-dessous vous pouvez voir la bête en action, que j’ai paramétré pour l’occasion en mode fenêtré. Vous pouvez si vous le préférez la lancer en mode plein écran, où vous ne verrez plus de barre de menu et de contrôles. Tout se fera alors au clavier et à la souris.

La taille des vignettes d’aperçu peut être modifiée et si le background ne vous plaît pas il sera possible de le modifier. Ce qui est intéressant c’est que vous pouvez le mettre en transparence, ce qui vous permettra de surveiller ce qui se passe en arrière-plan.

Ici vous pouvez voir un fauve, un vrai, et accessoirement le mode (fenêtré) plein écran, qui dispose d’une barre affichant les vignettes d’aperçu.

Vous pouvez voir aussi les contrôles Next/Prev et en haut à gauche, l’aide (Help), les contrôle de rotation et le contrôle Undo.

NB : Petit détail grincheux, le Help qui se vautre sous les contrôles c’est pas beau!

Sur cette dernière capture vous pouvez voir les options de configuration qui ne sont pas nombreuses, mais suffisantes pour ce qui est demandé à cette application. Il n’en faut pas plus…

Alors malgré quelques effets de transition assez réussis ça reste ultra minimaliste, mais ne vous y fiez pas. Tout est là.

Vous pouvez naviguer dans vos répertoires, vous disposez d’un mode d’aperçu assez sympa et paramétrable, vous pouvez faire pivoter vos images, copier, couper, renommer ou supprimer vos images et au final, c’est tout ce qu’on attends d’une visionneuse d’images.

Si ça vous tente et que vous tournez sur Ubuntu, vous pouvez passer par le lien évoqué au début de l’article pour vous procurer les binaires ou les sources de l’application. Si vous tournez sur Arch Linux (AUR) et dérivés (y compris Manjaro), vous pouvez également installer Limoo à l’aide de ces quelques lignes de commande :

Arch Linux et dérivés :

yaourt -S limoo

Amusez-vous bien.

via hecticgeek.com

PS : Quel beau matou quand même!

Original post of La vache libre.Votez pour ce billet sur Planet Libre.