Informatique – Page 51

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.

JavaScript: Enlever les doublons d’un tableau

La fonction suivante permet de se débarrasser des doublons présents dans
un tableaux avec élégance.

//cleanArray removes all duplicated elements
function cleanArray(array) {
  var i, j, len = array.length, out = [], obj = {};
  for (i = 0; i < len; i++) {
    obj[array[i]] = 0;
  }
  for (j in obj) {
    out.push(j);
  }
  return out;
}

On va créer un tableau associatif avec chaque valeur présente dans le
tableau passé en paramètre. Ainsi, lorsqu’un doublon est rencontré,
l’ajout d’un champ avec le même index n’a pas d’effet. On parcourt
ensuite ce tableau et l’on stocke les indexes dans le tableau out qui
sera retourné.

Exemple:

var nbr = [42, 101010, 7, 42, 7, 42, 101010];
var newNbr = cleanArray(nbr);
console.log(newNbr);

Qui donnera:

["42", "101010", "7"]

Migrer son WordPress

C’est effectif depuis jeudi soir, Unicoda dispose maintenant d’un serveur tout neuf. Effectuer une migration de WordPress est en fait relativement simple pour peu qu’un terminal ne vous fasse pas peur et sinon, des interfaces graphiques et autres plugins peuvent parfois vous simplifier encore le travail. Le nom de domaine ne changeant pas, la procédure en est encore simplifiée.

On arrive donc sur un serveur vierge de tout paquets, les paquets de base et c’est tout. Quelques installations s’impose donc, à coup d’aptitude ou de apt-get si vous préférez. Avant toute chose, on met à jour les informations concernant les paquets avec aptitude update, puis mise à jour via aptitude safe-upgrade. Suite à ces manipulations, un petit dpkg-reconfigure tzdata s’impose, histoire d’avoir une heure correcte sur le serveur. L’heure de Moscou, c’est bien beau, mais pour avoir des logs lisibles, une heure française c’est mieux (Bonjour à nos amies russes et biélorusses au passage). Arrive donc la phase d’installation à proprement parler. Via aptitude install, on installe donc les paquets suivants: php5, mysql-server, php5-mysql, php5-gd, vsftp.

Vient ensuite la configuration de vsftp, serveur FTP comme vous avez pu le deviner. On édite le fichier /etc/vsftpd.conf et on relance avec /etc/init.d/vsftpd restart pour que les modifications soient prises en compte.

On s’attaque ensuite à la partie MySQL pour préparer la nouvelle base de données de notre site à accueillir celle provenant de l’autre serveur : mysql -p. Puis dans votre invite de commande MySQL:

>CREATE DATABASE nomBaseDeDonnees;

>GRANT ALL PRIVILEGES ON nomBaseDeDonnees.* TO "NomUtilisateur"@"hostname" IDENTIFIED BY "motDePasse";

>FLUSH PRIVILEGES;

>EXIT;

Concernant les différents paramètres, nomBaseDeDonnes correspond au nom que vous donnez à votre base de données, nomUtilisateur parle de lui-même, hostname est généralement à remplacer par localhost et motDePasse c’est limpide. Votre base de données est donc prête à accueillir vos anciennes informations relatives à vos articles, utilisateurs, commentaires, etc…

Il faut également récupérer le contenu de votre dossier wp-content qui contient toutes les images que vous avez pu héberger sur votre site, les thèmes et les plugins. Un téléchargement du dossier via un client FTP fonctionnera très bien. Compresser le dossier avant envoi vous permettra de patienter moins longtemps pendant le téléchargement de vos données et surtout, pendant leur upload à venir. Une fois le dossier téléchargé, on l’upload justement vers le nouveau serveur; cette étape prend du temps surtout si votre dossier n’est pas compressé et que votre upload se résume à du 36Ko/s. On peut ensuite remplacer le dossier wp-content de notre installation toute fraîche de WordPress par celui de notre ancien site.

Il faut également transférer les données de l’ancien base de données et les injecter dans la nouvelle. La commande suivante vous permet de récupérer les anciennes données dans un fichier:

mysqldump --add-drop-table -h mysqlhostserver -u mysqlusername -p databasename | bzip2 -c > fichier.bak.sql.bz2.

Au niveau des paramètres, localhost pour mysqlhostserver, votre nom d’utilisateur pour mysqlusername, le nom de l’ancienne base de données à la place de databasename et remplacer fichier par le nom que vous voulez pour votre sauvegarde des données. On récupère ensuite le fichier via notre ftp, on l’upload à son tour vers le nouveau serveur, on décompresse au préalable le fichier: bzip2 -d fichier.bak.sql.bz2 et on injecte les données dans notre nouvelle base de données:

mysql -h mysqlhostserver -u mysqlusername -p databasename < fichier.bak.sql

Avec localhost pour mysqlhostserver, votre nom d’utilisateur mysql pour mysqlusername et le nom de votre nouvelle base de données en lieu et place de databasename. A ce stade, votre nouveau site est presque opérationnel, il ne reste plus qu’à faire pointer le nom de domaine vers le nouveau serveur, configurer apache (Doc Ubuntu) et éditer le fichier wp-config.php de votre nouveau WordPress avec les paramètres utilisés pour la création de la nouvelle base de données.

On trouve la plupart des informations dont on a besoin sur le web, et notamment sur le site de WordPress. Quelques heures suffisent donc à effectuer la migration d’un site WordPress vers un nouveau serveur si on conserve le même nom de domaine, le plus long étant à mon sens, l’upload du dossier wp-content.