[Conky] Script de démarrage

Conky est maintenant configuré… Prochaine étape, le démarrage automatique à l’ouverture de la session. On se place donc dans notre home où on va créer un dossier .conky pour y placer le script: mkdir .conky. On va ensuite écrire le script dans un fichier que l’on nommera .conkyboot.sh : vim .conkyboot.sh; utilisez ici l’éditeur avec lequel vous êtes à l’aise, nano, vi, vim ou autres.

Le script est très simple et tient en trois lignes:

#!/bin/bash
sleep 20;
conky -d;

Il faut ensuite rendre le fichier exécutable: chmod +x .conkyboot.sh.
Dernière étape, programmer l’exécution du script à chaque démarrage de la session. Pour cela, onglet Système – Préférences – Applications au démarrage. Puis Ajouter, et compléter le champ avec /home/user/.conky/.conkyboot.sh en remplaçant user par votre nom d’utilisateur. Remplissez le champ Nom avec Conky par exemple.

Et voilà, votre conky devrait désormais s’afficher automatiquement 20 secondes après l’ouverture de votre session.

[Vidéo] Court métrage Plurality

Voilà maintenant un peu plus d’une semaine que le court métrage Plurality peut être visionner sur Youtube. Ce film de Dennis Liu nous plonge dans un New York sous surveillance. Une surveillance comme toujours imposée au nom de la sécurité et de la commodité. La moindre action s’effectuant grâce à votre ADN, élément unique permettant de vous identifier. Néanmoins, dans ce monde Orwellien, des pluralités sont régulièrement constatées…

Après une dizaine d’heure de travail, j’ai pu ajouter les sous-titres anglais et français sur le site Universal Subtitles. Il y a malheureusement quelques phrases manquantes que je n’arrive pas à décrypter, n’hésitez donc pas à améliorer les sous-titres! Voilà le lien vers la vidéo: PLURALITY.

Une vidéo qui n’est donc pas sans rappeler des œuvres littéraires bien connues comme bien sûr 1984 de George Orwell. Dans le même esprit et plus récent, on pensera également à l’excellent livre d’Alain Damasio: La Zone du Dehors.

Sur ce, bon visionnage!

Git(hub): les commandes pour démarrer.

Voilà les commandes utiles pour récupérer un dépot github et commencer à développer son projet ou contribuer, ici en prenant l’exemple de npmconf.

On récupère les données du dépôts
git clone https://github.com/username/npmconf.git
cd npmconf
On ajoute le dépôt parent dans le cas d’un fork, pour être en mesure de faire des merges.
git remote add upstream https://github.com/isaacs/npmconf.git
On récupère les données du dépôts parent
git fetch upstream

Un petit point de configuration pour pouvoir faire un push correctement.
On édite .git/config:

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = https://github.com/vvision/npmconf.git
[branch "master"]
remote = origin
merge = refs/heads/master
[remote "upstream"]
url = https://github.com/isaacs/npmconf.git
fetch = +refs/heads/*:refs/remotes/upstream/*

On remplace la ligne url = https://github.com/vvision/npmconf.git par
url = https://username@github.com/vvision/npmconf.git .
En mettant votre nom d’utilisateur en lieu et place de username.
De cette façon, il n’y a plus qu’à entrer son mot de passe lors du push.

[Conky] Afficher son IP publique

J’avais laissé Conky de côté un petit moment, et j’ai pris le temps ce soir de le réinstaller. Pas encore touché au démarrage automatique lors de la connexion, je veux d’abord vérifier s’il le fait de lui même ou pas. Mais trêve de bavardage, le sujet qui m’intéresse est celui de l’affichage de l’IP publique. J’avais déjà trouver comment afficher mon adresse ip locale et l’adresse de la passerelle.

La solution que j’ai trouvé consiste à aller interroger le site ip.nu avec curl. Néanmoins, le taux de rafraîchissement de conky étant de 2s dans mon cas, il faut trouver un moyen de lancer la commande à un intervalle beaucoup plus long. Notre adresse IP publique n’étant de toute façon pas susceptible de changer toutes les 10s.

Pour ce faire, on utilise donc texeci tempsEnSeconde qui nous permet d’appeler la commande à intervalle de temps régulier. On a donc: texeci 400 curl ip.nu. Toutes les 5 minutes, on interroge donc le site ip.nu. Toutefois, en l’état, le retour est le suivant:

<html>
    <head>
        <title>ip</title>
    </head>
    <body>
        Your IP address is 80.42.124.42
    </body>
</html>

Pas très pratique à afficher dans notre conky. Prochaine étape donc, la récupération dans toute ces balises, de l’adresse ip avec comme vous le devinez certainement un petit grep et une regex. Ce qui nous donne: curl ip.nu | grep -Ewo ‘\b([0-9]{1,3}\.){3}[0-9]{1,3}\b’. Résultat de cette commande: 80.42.124.42. Nous avons notre ip! Par précaution, on peut encore appliquer un uniq, au cas le site se mettrai à renvoyer plusieurs fois l’ip dans sa requête. Donc finalement: curl ip.nu | grep -Ewo ‘\b([0-9]{1,3}\.){3}[0-9]{1,3}\b’ | uniq. On notera au passage que Richard M. Stallman est l’un des auteurs de uniq

AUTHOR
       Written by Richard M. Stallman and David MacKenzie.

On peut maintenant ajouter notre code dans le fichier de conf .conkyrc, ce qui nous donne:

${alignc}Public IP: ${texeci 400 curl ip.nu | grep -Ewo '\b([0-9]{1,3}\.){3}[0-9]{1,3}\b' | uniq}

 

Test Js avec Mocha et Chai

Deux outils bien utiles pour réaliser des fichiers de tests. Mocha est framework de test écrit en Javascript et une bibliothèque d’assertion pour Node

Avec Mocha, on peut facilement décrire sa situation de test puis vérifier l’état des différents tests liés à celle-ci.
Plusieurs dispositions sont disponibles pour l’affichage des résultats des tests. Pour ma part, j’utilise le reporter « spec ».
Il est également possible de préparer l’environnement de test en utilisant before ou after par exemple, pour effectuer des actions avant les situations de test.

Chai nous permet quant à lui de vérifier et comparer la valeur de variables ou de propriétés avec la valeur attendue dans le cas d’un fonctionnement « normal ».
Différentes possibilités d’écriture, le style assert ou le style BDD décliné en deux colorations: expect et should.

Pour l’utilisation d’assert: var assert = require(‘chai’).assert;

Un petit exemple de test combinant Mocha et Chai.

var assert = require('chai').assert,
question = undefined,
answer = 42;

describe('Question of Life and the Universe', function() {
  it('answer to this undefined question should be 42', function(done) {
    assert.isUndefined(question, 'Answer is 42, but what is the question');
    assert.equal(answer, 42);
    done();
  });
});

Sur cette exemple, il est possible d’enchaîner les it dans un même describe et les describe dans un fichier de test.
Notons qu’il est également possible de faire un describe dans un describe.

Chaque test possède un temps max pour être réalisé, par défaut 200ms il me semble.
Il est possible de modifier ce temps de timeout à l’appel de la commande mocha via le paramètre dédié.
Sinon, on peut spécifier le timeout pour chaque it grâce à this.timeout(tpsEnMs); .

Autre point intéressant, la présence de done comme paramètre de function au niveau du it change la caractère synchrone ou asynchrone de votre test.
Avec done, mocha ne passe au it suivant que lorsque le it en cours à renvoyé done.
Inversement, omettre done pour un it permet donc à mocha de continuer automatiquement sur le test suivant.

Pour conclure, le duo Mocha/Chai permet d’avoir des fichiers de test avec une hiérarchie lisible. Le fonctionnement et la syntaxe viennent rapidement.
Enfin, avoir transformé une batterie de test écrit en vows en tests utilisant Mocha et Chai, m’a montré qu’utiliser le duo que je viens de présenter simplifie beaucoup les choses.