PROJET AUTOBLOG


Blog-Libre

Site original : Blog-Libre

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Représentation et déplacement

samedi 2 septembre 2017 à 09:00

Je viens du monde Windows et je suis en train d’embrasser le monde Linux professionnellement. Je suis littéralement perdu, je cherche des repères, je tâtonne pour m’organiser. Évidemment j’ai des bases, une grosse culture mais il y a un monde entre la culture et la pratique, entre arpenter le chemin et connaître le chemin.

Windows est surtout utilisé avec un environnement graphique et l’explorateur Windows (explorer.exe). Sur GNU/Linux les serveurs sont généralement sans environnement graphique et utilisés en mode console (shell).

Sur Windows on aura tendance à parcourir l’arborescence des dossiers, exemple avec l’explorateur Windows :
C:\ --> C:\Windows\ --> C:\Windows\system32\ --> C:\Windows\system32\config\

Sur GNU/Linux on va traverser l’arborescence des dossiers, exemple en ligne de commandes :
cd / --> cd /var/log/apache2

On se déplace de manière directe, rapide et transversale en ligne de commandes et de manière visuelle, lente et continue avec un gestionnaire de fichiers. Chaque manière de se déplacer est différente mais elles sont complémentaires.

J’ai remarqué que je me représentais bien mieux l’espace avec un gestionnaire de fichiers. Je « vois » mieux donc je me déplace mieux (mais pas nécessairement plus rapidement). Le problème en se déplaçant de manière directe avec la ligne de commandes, c’est qu’on se base sur notre prétendue connaissance de l’espace qu’on parcourt. On croit connaître l’arborescence par cœur, de tête. A cause de cela on passe à côté de l’inconnu : fichiers cachés, vieux fichiers oubliés, nouveaux dossiers, trucs bizarres crées par des programmes/scripts etc.

Il me semble que dans un nouvel environnement, on devrait commencer par arpenter le chemin car on ne le connaît pas réellement, il peut y avoir des surprises. Une fois qu’on a bien parcouru le système de fichiers, on peut se rendre directement à destination pour gagner du temps. On connaît mieux le chemin et ses particularités.

Du coup en ce moment j’utilise pas mal cd && mkdir -p tmpmnt; sshfs cascador@blog-libre.org:/ tmpmnt; (caja tmpmnt &> /dev/null &) et j’en viens à remettre en cause le « tout » ligne de commandes.

Canard ou lapin ?

vendredi 18 août 2017 à 08:00

Bon alors la question du jour : C’est un canard (duck) ou un lapin (rabbit) ?

Je trouve que c’est un excellent exemple pour démontrer que selon le point de vue de chacun (où on se place pour regarder), on a une vision différente des choses.


J’ai mis environ 9h à écrire l’article Un mot : serveur. De mon point de vue c’est énorme mais j’étais dans une démarche inédite et importante pour moi : Je me suis réapproprié les mots utilisés et j’ai tenté de rejoindre les lecteurs.

Notre impuissance – Les mots finissait sur : « Je m’interroge en tant que blogueur sur notre impuissance à nous faire comprendre par l’autre. Cette impuissance qui fait qu’on s’éloigne alors que les mots devraient nous permettre de nous rapprocher. Je rattache tout cela au fait que je m’exprime sur le net et que j’accepte, même si ça m’est difficile de l’accepter, qu’on ne comprenne pas tout ce que je dis. J’accepte notre impuissance, celle des mots ». Je ne reviens pas dessus mais je me suis battu contre ça et après 9h de bataille, j’estime avoir gagné. La définition que j’ai donné du mot serveur me donne satisfaction (même si à travers les commentaires reçus, on peut encore l’améliorer).

Je tenais à remercier chaleureusement les personnes qui ont participé dans les commentaires de Un mot : serveur, merci ! Je vous invite très chaudement à les lire car au fond mon article était moins important que ce qu’il a permis de réaliser dans les commentaires : Chercher ensemble, être dans une démarche commune pour circonscrire le mot « serveur ».

Il faut bien comprendre que nous ne sommes pas dans le binaire vrai/faux, il n’y a pas une définition « vraie » sur laquelle tout le monde s’entendra et qui de facto exclurait toutes les autres définitions « fausses ». Nous avons des points de vue différents et nous essayons de trouver un consensus. C’est le langage, on essaie de se rapprocher, de converger, de se comprendre. Je vais paraître peut-être fleur bleue mais je trouve ça fantastique. Vraiment.


J’aime beaucoup l’article de A1, je cite quelques extraits avec son accord :

« Faire groupe, c’est se rassembler autour d’un commun. L’autre est toujours « à rejoindre », il n’est jamais proche d’entrée de jeu, sinon par illusion.

S’il est tout à fait normal d’avoir des opinions différentes, en rester là me semble confiner à l’impuissance. En effet, se satisfaire de ces opinions, comme autant de postures différentes, pose la question de l’espace commun. Des postures incompatibles ne serait-ce qu’en partie ne sauraient s’incarner collectivement autrement, au choix, que dans le conflit (« j’ai LA vérité et pas toi ») ou dans le relativisme généralisé (« tu as la tienne, j’ai la mienne, et tout va bien: on fusionne, ou on ne se croise pas »). Par conséquent, ni le conflit ni le relativisme absolu ne me semblent viables. L’un et l’autre nous isolent alors que nous ne sommes et ne devenons nous-mêmes qu’avec l’Autre. Je crois donc important de se placer entre la revendication de détenir « LA vérité » et la tentation de céder au relativisme.

L’alternative qui me semble la plus pertinente, c’est de proposer à chacun d’examiner avec une critique radicale en quoi nos perceptions sont validées/invalidées par ce réel qui nous est extérieur. Il s’agit de le considérer comme toujours trop confus et de le questionner pour travailler à son impossible clarification. Cette démarche est individuelle et intime. L’enjeu n’est ni l’autre ni le rapport à ce dernier, mais bel et bien un rapport critique à soi.

Pour illustrer, imagine, lectrice, lecteur, en 2 dimensions: chacun est un point noir placé sur une feuille de papier blanche. Chacun est à la fois « situé » et « voit son regard orienté » dans une direction précise, ce qui illustre la diversité de nos perspectives, conditionnées par nos points de vue. Quelque part sur la feuille se trouve un objet non circonscrit que chacun, par définition, voit à midi et devant sa porte. Par itération, il s’agit pour chacun de savoir si midi correspond plutôt à 11h59 ou 12h01, et si la porte ne serait pas plutôt la boite aux lettres, ou la clôture du jardin.

Je fais l’hypothèse que de tels mouvements individuels, itérativement répétés, sont un moyen de nous rassembler autour de cet objet afin de le caractériser par ce que nous en percevons et qui ne saurait s’avérer qu’être complémentaire. Nous ne pouvons pas le connaître, ni individuellement ni collectivement, par contre nous le circonscrivons d’autant mieux que nous sommes nombreux à l’entourer. Comme si la nature de l’objet, diffractée autour de lui et insaisissable, était intelligible fragment par fragment.

Les opinions différentes et incompatibles deviennent dès lors une richesse: la convergence asymptotique vers ce même objet entraîne l’émergence d’un vocabulaire commun et d’une démarche cohérente sans être coercitive et sans que quiconque puisse se prévaloir d’être indispensable, quoique chacun puisse aider à des degrés différents. »

Un mot : serveur

lundi 14 août 2017 à 19:30

Depuis une réflexion partagée avec A1, je suis particulièrement attentif aux mots que j’utilise dans mes articles. J’essaie autant que possible d’utiliser les bons mots car j’ai compris que c’était la matière première qui permettait de vous rejoindre. C’est très difficile.

Il m’est déjà arrivé d’utiliser un mot alors que l’idée que je m’en faisais était totalement différente. Imaginez que vous pensiez à une baleine et que le mot que vous utilisez pour nommer cette idée est espadrille. Oui c’est comique mais pour se faire comprendre c’est une vrai catastrophe.

A1 m’avait également parlé de la difficulté à se faire comprendre lorsqu’une idée est définie par un mot dans une langue mais que ce mot est absent dans une autre. Vous connaissez tous : « Free as in free speech, not as in free beer ». Free peut signifier deux mots, libre ou gratuit. Je trouve ça fascinant. Comment prendre conscience d’une idée si on n’a pas le mot ? Je vois une baleine mais le mot n’existe pas dans le dictionnaire, comment me faire comprendre ? Comment rejoindre l’autre quand un des deux n’a pas l’outil (le mot) ?

Au fil de mes articles j’ai rencontré une nouvelle difficulté, des mots qui peuvent signifier tellement de choses qu’au final ils ne signifient plus grand-chose. C’est le cas du mot serveur (informatique). Si je demandais définissez serveur informatique, ce serait un gros bordel. Alors que les mots sont principalement là pour nous permettre de communiquer, nous rejoindre sur un terrain commun, certains mots sont tellement peu précis qu’ils finissent par nous diviser.

Je me retrouve donc, si je veux être bien compris, à devoir définir un mot. C’est particulièrement drôle je trouve et en même temps il y a une réappropriation du langage. Cette réappropriation m’est nécessaire si je veux vous rejoindre, si je veux qu’il soit possible qu’on parle de la même chose.

Je m’appuie sur l’article Serveur informatique de Wikipédia. Voici comment je définis un serveur, ma définition d’un serveur informatique : Dispositif informatique matériel ou logiciel fonctionnant en permanence, offrant un ou plusieurs services sur un réseau en répondant automatiquement à des requêtes provenant d’autres dispositifs informatiques (les clients).

Je ne sais pas si vous vous rendez bien compte de la complexité à définir un simple mot. Pour moi ce qui définit principalement mais pas suffisamment un serveur c’est qu’il fonctionne en permanence :

Pour info « serveur » (informatique) est défini ainsi sur le CNRTL : « Organisme qui exploite un système informatique permettant à un demandeur la consultation et l’utilisation directes d’une ou de plusieurs banques de données ». C’est bien si on considère « directes » comme signifiant en permanence et automatiquement. La définition reste vague englobant ainsi beaucoup de cas, c’est en même temps sa faiblesse, c’est au final peu clair. Je doute qu’à partir de la définition quelqu’un puisse retrouver le mot. C’est assez drôle de voir le mot « organisme » utilisé. J’aurai remplacé « demandeur » par client, j’aurai viré « d’une ou de plusieurs banques » pour faire ressortir seulement « données ».

Je considère la définition Larousse comme mauvaise : « Ensemble matériel et logiciel, branché sur un réseau télématique et mettant à la disposition des utilisateurs de ce réseau des banques de données ou de programmes spécialisées ; organisme qui assure ce service ». Je trouve notamment le « Ensemble matériel et logiciel » très bancal. Personnellement bien qu’une machine virtuelle s’appuie et fonctionne sur un matériel physique (pc, serveur…), je considère qu’une VM est uniquement logicielle. C’est un gros paquet de données qu’on peut copier sur une clé USB et faire fonctionner sur un autre matériel physique par exemple.

Voilà j’ai défini pour moi ce qu’était un serveur informatique. Je me suis beaucoup amusé et passionné à écrire cet article, maintenant je vais aller prendre ma dose de Prozac. La question qui fâche : Êtes-vous d’accord avec cette définition ?

Setup d’un projet Webpack avec Babel pour ES2017, VueJS, Karma, Mocha, Chai et toute la clique

samedi 12 août 2017 à 16:31

Note : Malgré tous mes efforts, je n’ai pas réussi à faire fonctionner Karma, Webpack et PhantomJS correctement ensemble. L’ensemble des problèmes rencontrés est résumé en anglais ici. Concrètement, nous rencontrons des erreurs lors de l’exécution de Karma qui ne sont pas les mêmes d’un environnement à un autre et qui semblent tous liés à un problème de transpilage côté Webpack. Il est donc très probable qu’on abandonne Karma, Webpack et PhantomJS très rapidement pour d’autres choses.

Ça fait longtemps que j’ai pas écrit un article technique. Et comme il se trouve qu’il n’y a pas si longtemps, j’en ai un peu chié pour faire la config correcte d’un environnement JS pour un projet Django, je me disais que c’était une bonne occasion de s’y remettre.

Soyez prévenus, tout de même, que je ne supporte pas Node, NPM et tout son écosystème. Il risque donc d’y avoir dans cet article une pointe de mauvaise foi.

Introduction dans tes orifices

Merde… Je me mets à écrire des articles à la Sam&Max. Je vais mal finir…

Il y a très peu de temps, j’ai commencé à contribuer à SocialHome, le projet de réseau social décentralisé de Jason Robinson, lui aussi ancien contributeur pour diaspora*. Dans la vie, Jason est un mec bien. Mais il est aussi développeur Python/Django. C’est donc tout logiquement que SocialHome est développé en Python/Django. Mais SocialHome n’en est encore qu’à ses tous premiers stade de développement. Jason se concentre pour le moment sur le développement de back-end et de federation, une bibliothèque de support des protocoles de réseaux sociaux décentralisés 1. Le front-end de SocialHome est donc pour le moment… comment dire… Lacunaire. Ouais, bon, Ok. Il est dégueulasse. C’est de l’insertion de HTML en jQuery, ça repose Grunt et Bower que plus personne n’utilise… Bref, ça a besoin d’un bon coup de ménage.

Fort heureusement pour moi, le front-end n’est pas très avancé. Le projet n’est pas bloqué avec des technos obselètes comme peut l’être diaspora* et son core-développeur est très réactif dans les revues de code et très présent sur IRC 2. Et il se trouve que le projet avait besoin d’un développeur front. Comme il se trouve que j’ai passé mes trois dernières années à développer le l’interface utilisateur de diaspora* et que je sortais d’une mission de développeur ReactJS, je me suis dévoué pour prendre ce rôle. Et, cela étant dit, vu à quel point l’écosystème Javascript et NodeJS me révulse, je dois être un poil maso sur les bords.

Étape 1 : Webpack, Babel et VueJS

Bon, j’ai pu tester ReactJS/JSX lors de ma dernière mission pro. Et je trouve que c’est plutôt de la bonne came. Mais, pour ce projet, j’avais envie de tester VueJS, que le copain Marien Fressinaud utilise pour l’un de ses projets et dont j’ai entendu de bons échos. Mais comme chuis un mec un peu bourrin, j’ai pas voulu commencer par la méthode douce « j’inclue la biblio VueJS et je fais un peu de templating dans mon objet Javascript ». Trop facile. Nan, moi j’ai préféré sortir l’artillerie lourde dès le début : Webpack et les single-file components 3. À ma décharge, SocialHome a besoin de moderniser son écosystème de composants JS. Le Gruntfile, c’est mignon, mais on a fait mieux, depuis.

J’en profite d’ailleurs émettre ici une petite note sur l’écosystème Javascript : il pue la merde 4. Alors, j’ai suffisamment gueulé dans le passé sur Java et sa communauté. Et c’est vrai que le langage est syntaxiquement tout pérave. Mais il possède l’un des écosystèmes les plus solides et matures que j’ai pu rencontrer. Maven a imposé un ensemble de conventions fortes qui n’ont pas bougé avec le temps et sont restés. Même si vous choisissez un des moteurs de compilation qui sont arrivés après comme Gradle ou SBT. Toute la configuration du projet se trouve dans votre

pom.xml
. Que ce soit ses dépendances, sa chaîne de compilation ou la configuration de ses plugins. Tout est dans le même fichier. Et c’est pareil pour Gradle ou SBT.

Par rapport à Maven, l’écosystème NodeJS donne l’impression d’être revenu 10 ou 15 ans en arrière. NPM et son

package.json
  ne font que gérer les dépendances… à l’exception de commandes shell que vous pouvez déclarer et exécuter avec
npm run <commande>
. Mais c’est pas plus avancé qu’un Makefile. Alors pour des projets plus gros, il vous faudra un autre moteur de compilation. Et il en existe plus d’une dizaine : Grunt, Gulp, Mimosa, Brocolli ou encore Webpack pour les plus connus. De toutes façons, tous les 6 mois il y en a un qui est créé et un qui tombe en désuétude. Donc si vous créez un setup JS, gardez en tête que, de toutes façons, vos choix ne sont pas pérennes. Et, bordel, même pour la gestion de dépendances, c’est la merde. Certes, NPM est un standard. Mais apparemment, c’est suffisamment pété pour qu’en plus de ça, certains projets rajoutent un deuxième moteur de gestion de dépendances. Bower a eu un gros succès il y a un an ou deux, maintenant, Yarn — alors… pas le Yarn de Hadoop, on est d’accord, hein ? — tend à s’imposer sur les nouveaux projets.

Et puis, puisqu’un seul fichier pour configurer tout votre projet, c’est beaucoup trop simple, chaque nouvel outil a sa propre manière de déclarer sa configuration. Il n’est encore venu à l’idée de personne qu’on pouvait modifier NPM pour intégrer un système de plugins configurables dans le

package.json
comme on peut le faire avec Maven…

Bref…

Étape 1 : Webpack, Babel et VueJS (bis repetita)

Les dépendances NPM

Donc, moi j’ai décidé de faire de l’ES2017. Parce que l’écosystème JS est suffisamment aux fraises pour devoir en plus se taper tous les trous du langage qui ont commencé à être fixés avec ES2015. Et puis j’ai décidé d’utiliser Webpack pour coordonner tout ça parce que plouf, plouf. De toutes façons, dans 2 ans une autre ConnerieJS l’aura remplacé. Commençons par inclure toutes nos dépendances dans le

package.json
:

"devDependencies": {
  "babel-preset-env": "^1.6.0",
  "css-loader": "^0.28.4",
  "node-sass": "^4.5.3",
  "sass-loader": "^6.0.6",
  "style-loader": "^0.18.2",
  "vue-loader": "^12.2.2",
  "vue-style-loader": "^3.0.1",
  "vue-template-compiler": "^2.4.1",
  "webpack": "^3.2.0"
},
"dependencies": {
  "vue": "^2.4.1",
}

Petite note sur

babel-preset-env
: au tout début, j’ai inclu les dépendances
babel-core
,
babel-loader
et
babel-preset-es2017
. Et puis je me suis rendu compte, en ajoutant un test unitaire qu’ils fonctionnait avec Firefox mais pas avec PhantomJS. Très étrangement, PhantomJS se vautrait sur la syntaxe lambda. Tout se passait comme si la syntaxe ES2015 n’était pas transpilée par Babel. Et, en fait c’est exactement ce qui se passait… Naïvement, j’ai pensé que 
babel-preset-es2017
incluait toutes les spécifications ES depuis ES2015. Ce n’est pas le cas. 
babel-preset-es2017
ne transpile que les fonctionnalités nouvelles dans la spécification 2017 d’ES. Les lambdas font partie de la spécification 2015, que Firefox supporte, mais que PhantomJS ne supporte pas.

Conclusion : vous faites pas chier. Adoptez

babel-preset-env
. Ça contient toutes les vitamines et les minéraux dont votre ES a besoin pour transpiler.

Chez nous, a SocialHome, on a aussi choisi SCSS, pour notre CSS.

node-sass
,
sass-loader
  et
style-loader
nous permettent de transpiler notre SCSS en CSS bien gras avec des grumeaux. Enfin,
vue-loader
va nous permettre de transformer nos single-file components en JS et en CSS compréhensibles par le navigateur.

La config Webpack

Notre

webpack.config.js
. Attention… C’est parti :

const path = require("path")
const webpack = require("webpack")

module.exports = {
    entry: {
        stream: path.resolve(__dirname, "socialhome/streams/app/main.js")
    },
    output: {
        path: path.resolve(__dirname, "socialhome/static/js"),
        filename: "webpack.[name].js"
    },
    module: {
        loaders: [
            {
                test: /.js$/,
                loader: "babel-loader",
                exclude: /node_modules/,
                query: {presets: ["env"]}
            },
            {
                test: /\.scss$/,
                loaders: ["css-loader", "sass-loader"]
            },
            {
                test: /\.vue$/,
                loader: "vue-loader",
                options: {
                    loaders: {
                        scss: ["vue-style-loader", "css-loader", "sass-loader"],
                        js: "babel-loader"
                    }
                }
            }
        ]
    },
    resolve: {
        modules: [
            path.resolve(__dirname, "socialhome"),
            path.resolve(__dirname, "node_modules")
        ],
        alias: {vue: "vue/dist/vue.js",}
    },
    stats: {colors: true},
    devtool: "cheap-module-source-map"
}

Yolo !

Petite note sur la partie :

entry: {
    stream: path.resolve(__dirname, "socialhome/streams/app/main.js")
},
output: {
    path: path.resolve(__dirname, "socialhome/static/js"),
    filename: "webpack.[name].js"
}

La plupart des exemples de config Webpack que vous trouverez sur internet crachent tout votre JS dans un seul gros bundle. Pas très utile si vous avez une grosse application. Faire télécharger plein de code JS inutile parce qu’il ne sert que dans une autre page, c’est pas cool. Webpack vous permet de mettre un dictionnaire à la place d’une chaîne pour le champ

entry
. Ce qui permet de déclarer plusieurs fichiers d’entrée. La clef utilisée dans ce dictionnaire peut-être réutilisé pour générer plusieurs fichiers de sortie dans le champ
output
:
filename: "webpack.[name].js"
[name]
correspond à la clef dans le champ
entry
. Ici, notre config Webpack va générer un fichier
socialhome/static/js/webpack.stream.js
. Trop métal ! \m/ >.< \m/

À propos des loaders, et dans l’ordre :

  1. tous nos fichiers JS sont parsés et transpilés avec Babel ; rien d’extraordinaire ici,
  2. tous nos fichiers SCSS sont parsés avec SASS mais ne me demandez pas pourquoi il faut
    css-loader
      aussi ; j’en sais rien,
  3. nos single-file components sont parsés avec
    vue-loader
    .

vue-loader
accepte une option
loaders
qui permet de parser les fichiers les SFC avec différents loaders. Dans notre cas, le JS est parsé avec Babel pour pouvoir utiliser ES2017 dans nos SFC et le CSS avec SASS. Sachez que vous pouvez utiliser tout plein d’autres loaders. Vous pouvez utiliser Pug plutôt que Vue pour votre template ou Less plutôt que SASS pour votre style.

Pour la partie

resolve
, on ajoute un
alias: {vue: "vue/dist/vue.js",}
pour pouvoir faire
import Vue from "vue"
dans les SFC plutôt que import
Vue from "vue/dist/vue"
parce qu’on a la flemme.

Et, enfin,

devtool: "cheap-module-source-map"
nous permet d’avoir du source-mapping dans notre navigateur. Demandez pas comment ça marche, j’en sais rien. Farcissez-vous la doc si ça vous fait marrer. Moi, je trouve que j’ai déjà passé beaucoup trop de temps à configurer.

Dernière chose, pensez bien à rajouter une cible dev dans votre package.json pour transpiler tout ce fatras à la volée à chaque changement dans votre code. Sinon, ça va vous rendre dingue pendant le développement :

"scripts": {
    "dev": "./node_modules/webpack/bin/webpack.js --watch"
}

Normalement, avec ce setup, vous devriez pouvoir créer des fichiers

.vue
à la cool. Si c’est pas le cas, démerdez-vous. Je fais pas le service après-vente de l’écosystème NodeJS, non plus !

Étape 2 : PhantomJS, Karma, Mocha et Chai

Comme je vous l’ai déjà dit, l’écosystème NodeJS, c’est toupété. Parce que si vous vous imaginez qu’écrire des tests unitaires pour votre projet, ça devrait être simple comme ajouter une dépendance JUnit à votre

pom.xml
, les développeurs JS, eux, ils pensent pas comme vous, et ils vous emmerdent ! C’est donc, non pas 2, ni 3 outils que nous devons utiliser pour tester notre projet, mais 4. Parce que tagueule. Me demandez pas pourquoi Jason a insisté pour utiliser Karma + Mocha + Chai. Si j’avais su que c’était aussi naze, je l’aurais engueulé avant de lui dire d’aller se faire foutre et que, moi, j’utilisais Jasmine épicétou. Mais chuis un mec sympa, ché pas pourquoi…

Alors, PhantomJS, Karma, Mocha et toutes ces conneries new age avec des noms qui viennent d’orient pour faire mouiller les hipsters, cékoi ?

PhantomJS, c’est un navigateur en JS conçu pour faire tourner des TU sur votre font-end. Parce exemple pour tester que votre jQuery, il insère bien votre soupe HTML là où qu’il faut. Karma, c’est un moteur pour faire tourner vos tests. Mocha, c’est une biblio pour écrire vos tests et Chai, c’est une biblio pour faire les assertions de vos tests.

Vous voyez, la volonté de pas faire de choix et de pas avoir d’opinion tranchée, c’est aussi une autre plaie de l’écosystème Javascript. C’est comme ça qu’on se retrouve à avoir 76 outils pour faire la même chose, mais juste un peu différemment du voisin, plus 616 outils pour faire une seule chose un peu compliquée, mais qu’on veut laisser le choix au développeur de la couleur du cuir du fouet avec lequel il va devoir se punir lui-même. Et c’est comme ça qu’on empêche toute forme de convention d’émerger… À ce rythme-là, l’écosystème NodeJS sera mature dans à peu près 53 ans…

Ah, oui ! Je vous ai dit que Chai vous propose aussi 3 putains de syntaxes différentes pour faire vos assertions de tests !? Si, si

Les dépendances

Bon, allez, commençons par les dépendances :

"devDependencies": {
  "babel-preset-env": "^1.6.0",
  "chai": "~4.1.1",
  "css-loader": "^0.28.4",
  "karma": "^1.7.0",
  "karma-mocha": "^1.3.0",
  "karma-phantomjs-launcher": "^1.0.4",
  "karma-sourcemap-loader": "^0.3.7",
  "karma-webpack": "^2.0.4",
  "mocha": "^3.0.2",
  "node-sass": "^4.5.3",
  "sass-loader": "^6.0.6",
  "style-loader": "^0.18.2",
  "vue-loader": "^12.2.2",
  "vue-style-loader": "^3.0.1",
  "vue-template-compiler": "^2.4.1",
  "webpack": "^3.2.0"
},
"dependencies": {
  "vue": "^2.4.1",
}

Et là, il faut que je commence par un petit mot : si vous voulez utiliser la syntaxe

should
de Chai avec l’initialisation
import 'chai/should';
décrite dans la doc, faites bien attention à utiliser Chai 4. Ah oui, et puis la doc n’est pas correcte : il faut écrire
import 'chai/register-should';
. Parce nique les docs à jour, ok !?

Configuration de Karma

Pour configurer Karma, il faut créer un fichier

karma.conf.js
 . Ouais, nan, pas
karma.config.js
 , comme pour Webpack, nan, c’est trop simple. C’est bien
karma.conf.js
. Je vous ai dit que les conventions, c’était pas top le fort de l’écosystème NodeJS ?

Et donc, pour la config de Karma, ça se passe par là :

const wpConf = require("./webpack.config")
wpConf.devtool = "inline-source-map"

module.exports = config => {
    config.set({
        browsers:      ["PhantomJS"],
        files:         ["./socialhome/**/app/tests/**/*\.tests\.js"],
        frameworks:    ["mocha"],
        plugins:       [
            "karma-phantomjs-launcher",
            "karma-mocha",
            "karma-sourcemap-loader",
            "karma-webpack"
        ],
        preprocessors: {"./socialhome/**/app/tests/**/*\.tests\.js": ["webpack", "sourcemap"]},
        reporters:     ["dots"],
        singleRun:     true,
        webpack:       wpConf
    })
}

Nous, comme on a choisi de foutre de l’ES2017 partout, dans nos fichiers

.vue
comme dans nos tests, il faut que Karma passe par Webpack avant de lancer les tests. Donc on commence par récupérer la config :

const wpConf = require("./webpack.config")
wpConf.devtool = "inline-source-map"

Je sais pas pourquoi

wpConf.devtool = "inline-source-map"
. J’imagine que c’est une option de source-mapping plus performante à la compilation que
cheap-module-source-map
.

Pour l’option

files
  de la config, on peut spécifier un glob (voir la section File patterns). Pas besoin de lister les tests un par un comme je me l’était figuré au début, donc. Bien préciser dans l’option 
preprocessors
qu’on veut faire du
sourcemap
et du
webpack
(j’ai l’air intelligent à paraphraser ce qu’il y a écrit dans la conf, là, ou bien !?).

Enfin, ne pas oublier de donner la conf de Webpack qu’on a importée en début de conf :

webpack: wpConf
.

Normalement, avec ça, on devrait pourvoir faire des tests à la cool :

import "chai/register-should"

describe("Test", () => {
    it("is actually a test (RLY!?)", () => {
        true.should.equal(true)
    })
})

Ouais, ben c’était pour tester ma configuration de test ! Me jugez pas, hein !

Enfin, on rajouter une cible de test dans notre package.json :

"scripts": {
    "dev": "./node_modules/webpack/bin/webpack.js --watch",
    "test": "./node_modules/karma/bin/karma start"
}

Conclusionnage en mode relou

J’ai pas encore testé ma conf Karma sur des vrais tests de composants Vue. Mais j’ai confiance. Ça devrait bien se passer. Comme pour tout en JS ! Si le code qui est à l’origine de cet article vous intéresse, il est . Bien évidemment, si j’ai des ajouts ou des corrections à faire à cet article, elles viendront avec le temps.

Sur ce, la bise à tous et à toutes ! <3

Notes de bas de page :

  1. federation ne supporte pour le moment que le protocole diaspora* mais prévoit à terme d’en supporter d’autres, donc la spécification ActivityPub du W3C
  2. Je vous ai dit que c’est un mec bien !
  3. Je vous avais dit que j’étais maso.
  4. Ah, mais j’avais prévenu pour la mauvaise foi, moi ! Si vous êtes pas contents, c’est votre problème !

Pas de doute avec Firefox 57

vendredi 11 août 2017 à 07:00

Mon titre à deux balles chambre mon ami Cascador et son Comme un doute concernant le navigateur libre et open source Firefox et fait un appel du pied au billet de Gilles.

Vous ne le savez peut être pas mais Firefox prépare sa « révolution » avec sa version 57 pour courant septembre. Il est annoncé comme meilleur, donc plus rapide, léger et réactif lors de votre navigation avec son nouveau moteur de rendu, Quantum, et son architecture multiprocessus.

Rien de mieux qu’une installation pour vérifier cela. j’ai donc lancé la version beta numéro 57 pour me faire une idée. Si vous désirez faire coexister les versions 55 et beta 57 sur votre machine (Linux, Windows, Mac), je vous invite à suivre cette page.

Pour ma part, je navigue maintenant avec la version 57 et c’est une très, très grosse avancée ! Oui, Firefox se charge rapidement et affiche les pages merveilleusement vite ! C’est vraiment très plaisant.

L’API a été revu et les extensions devront être retravaillées pour un grand nombre d’entre elles.

En tout cas, je ne peux que conseiller la patience pour avoir le navigateur le plus éthique et respectueux de vos données privées au top du top, d’ici un bon mois.

Pour les plus pressés, laissez vous tenter par Brave (navigateur open source) que j’utilise comme deuxième navigateur sur mon ordinateur et en navigateur principal sur mon téléphone Android vu que c’est le plus rapide que j’ai testé jusqu’à présent, avec bloqueur de pubs bien sur.

Longue vie à Firefox qui prépare son retour en tant que meilleur navigateur, n’ayons pas peur des mots :)