PROJET AUTOBLOG


Blog-Libre

Site original : Blog-Libre

⇐ retour index

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 :)

Comme un doute

vendredi 28 juillet 2017 à 16:00

Firefox est un excellent navigateur, je pense qu’on sera tous d’accord là-dessus. Cependant j’ai comme un doute sur la fidélité de ses utilisateurs… notamment la mienne.

Partons de l’hypothèse que demain Firefox devienne deux fois plus lent que Chromium/Chrome ou encore que les extensions qui ont fait le succès de Firefox ne fonctionnent plus dessus, Firefox serait-il encore apprécié et utilisé ?

Je ne doute pas de l’existence de personnes convaincues par le Libre au point de faire passer leurs convictions avant leurs usages (en utilisant des outils plus éthiques mais moins fonctionnels par exemple). Je crois cependant que l’écrasante majorité des utilisateurs va « simplement » au mieux/meilleur.

En ce qui me concerne si Firefox perdait les principales extensions que j’utilise, je basculerais sur Chromium direct. A mon avis beaucoup de personnes se mentent sur leur prétendue fidélité aux logiciels libres. Sommes-nous avant tout des personnes qui utilisons, discutons et partageons autour de l’informatique, d’Internet, du Libre et de Linux ou des libristes ? Un libriste ne se poserait pas la question de quitter Firefox car c’est l’alternative la plus sérieuse techniquement et la plus respectueuse de la vie privée face à l’hégémonie de Chrome.

La plupart d’entre nous est technophile, nous aimons la technique, l’informatique, Internet, Linux et le Libre mais notre priorité première est, je le crois et je le crains, la meilleure solution technique et financière (gratuite…). Avant les convictions et l’éthique.

Finalement le doute que j’avais se transforme en reproche à mon égard, je suis avant tout fidèle à l’excellence technique devant l’excellence éthique.

Displate.com

mardi 18 juillet 2017 à 16:00

Il y a quelques semaines on m’a fait découvrir un site qu’il est bien. Depuis j’ai commandé un Displate pour l’offrir alors je me permets de vous en parler. PUB ! PUB ! PUB ! Oh mon dieu c’est de la PUB !

Un Displate c’est ça. Ouais vous allez devoir cliquer bande de feignasses. La pose est enfantine, c’est numéroté et signé (toujours un plus pour les collectionneurs), ça arrive par UPS dans un carton un peu plus grand que le displate, on peut trouver des codes promos pour le site facilement (Garden = 20%), pour l’achat de 1 displate c’est 10 arbres plantés et vous pouvez le renvoyer dans les 100 jours. Je vous invite cependant à faire une petite commande au début parce qu’on est parfois déçu entre l’image sur Internet et la réalité de l’objet.

Je vous fais part d’une petite sélection perso, je vais ainsi vous démontrer que je suis un homme de goût ;p

pacman

Your Brain on Video Games

Grouchy Cat

My epic 80s styled tribute to all those retro gamers

My retro gamer in an old but new arcade edition!

Be kind give some hugs!

Slurp!

I Love my WiFe

Viva la Resolucion

My painting « Achilles »

Stars Overflow

Je voulais prendre le chat pour fiston mais femme n’a pas voulu. Mes trois préférés pour finir.

Nightmare Before Christmas

3D Master Sword

It’s Dangerous to Go Alone

Sinon il y a la version « bonhomme », les Multiplate. Voici Search Team, 513 boules mais avec ça vous obtenez le respect et l’admiration de tous, vous chopez femme, homme, poulpe et vous avez le poil soyeux en prime.