L’environnement de travail

En tant que développeurs, nous passons d’innombrables heures assis face à notre ordinateur. C’est pourquoi il est primordial de bien s’équiper pour avoir une bonne productivité. De l’écran à l’IDE, j’ai pensé qu’il pouvait être intéressant de partager mes outils de travail.

Les écrans

Quand je parle d’écrans, ce n’est pas tant la marque ou la technologie de dalle qui importe – nous ne sommes pas designers – mais plutôt le nombre. En effet, comme nombre d’entre vous, mon unité centrale se résume à un laptop. Un Macbook Pro 15’’ en l’occurrence.

C’est amplement suffisant en terme de puissance, ça offre une bonne autonomie, l’écran de 15’’ permet de se débrouiller en mobilité, mais un seul petit écran est à mon humble avis suboptimal pour prétendre à une productivité honnête.

On a beau lutter contre le multitasking car notre cerveau n’est pas fait pour cela [en], nous jonglons quotidiennement entre une incroyable quantité de logiciels. Il est bien plus pratique de tout avoir sous les yeux à la fois, plutôt que de constamment naviguer entre différents bureaux virtuels.

bureau config trois écrans

Mon bureau à Lyon

Ainsi, l’écran du laptop sert généralement à héberger des consoles : connexions aux serveurs, outils de build ou de deploy. Et sur un autre bureau virtuel, la console de debug de Firefox.

L’écran du milieu alterne entre le navigateur et mon éditeur de code selon les projets en cours, tandis que l’écran de droite est principalement utilisé pour l’éditeur de code. J’ai également le ou les designs en split view quand je fais de l’intégration.

Partie software

Concentrons-nous maintenant sur les outils que nous utilisons au quotidien. En tant que développeur web, commençons par le navigateur.

Je l’ai déjà mentionné, j’utilise Firefox, la Developer Edition pour être précis. Je n’ai que deux plugins : RESTer pour travailler avec les API et VueJS devtools. En outre, je trouve le thème sombre très sympa, il s’assortit parfaitement avec les autres outils de dev au design souvent sombre aussi.

Éditeur de code

J’utilise Atom comme éditeur de texte. Il semblerait qu’il y ait en ce moment un fort engouement envers VS Code. Mais c’est un produit Microsoft, et les deux évoluant assez rapidement, la situation peut vite changer.

Atom répond à tous mes besoins, possède de nombreux plugins et est Open Source. Si l’envie me dit de modifier le comportement de quelque chose, ou d’ajouter une fonctionnalité, rien ne m’empêche d’ajouter ma brique à l’édifice.

En parlant des plugins, voici la liste des plugins que j’utilise dans Atom :

  • color-picker permet de choisir des couleurs à la pipette depuis différents endroits et d’appliquer le code couleurs directement dans Atom.
  • emmet permet fourni une auto-complétion aux hormones. Il permet en effet d’accélérer la saisie du code html en ne tapant que les sélecteurs CSS. Ainsi, section.container.product sera transformé après appuis sur tab en <section class="container product"></section>. Sacrée économie de frappes clavier !
  • file-icons ce petit outil permet simplement d’égayer votre interface en affichant des icônes spécifiques au différents types de fichiers dans les onglets et la treeview.
  • git-time-machine permet de visualiser l’ensemble des commits du fichier courant sur une timeline et de comparer le fichier actuel à un commit en particulier.
  • linter, comme son nom l’indique permet de linter les fichiers (automatiquement afficher les erreurs de syntaxe). Celui-ci est le linter de base, auquel viennent s’ajouter des linters spécialisés.
  • linter-eslint le linter phare du JavaScript. Associé à un fichier de config et/ou des presets, il supporte évidemment l’ES5, et 6+. Nous reviendrons sur sa configuration un peu plus tard.
  • linter-htmlhint vous l’aurez deviné, il permet de linter le HTML. Il possède également un fichier de conf sur lequel nous reviendrons.
  • linter-stylelint, c’est le linter par excellence pour le CSS. Il s’utilise aussi avec les préprocesseurs. Il y a là aussi un fichier de conf, nous verrons cela dans la partie suivante.
  • linter-less celui-ci permet de linter les fichiers Less. Oui, j’utilise Less. Simplement car c’est le premier que j’ai appris et qu’il me convient. Mais ne vous formalisez pas, il existe forcément un linter pour le Sass et pour Stylus. Ce linter valide simplement des détails spécifique à Less (tel que le fait que les variables sont déclarées etc). Par conséquent, il est à utiliser en complément de linter-stylelint.
  • linter-php, on se passe de description ici. Il n’y a pas de fichier de conf.
  • merge-conflicts est un résolveur visuel de conflit de merge. Ça permet de venir à bout des conflits rapidement et directement depuis l’éditeur.
  • pigments surligne les codes couleurs avec la couleur décrite pas le code. Il est compatible avec Less, Sass et Stylus.

Les linters

Les linters qui supportent des options permettent en général de les configurer de manière globale ou par projet. La configuration par projet apporte une plus grande flexibilité et présente l’avantage de pouvoir être commité avec ce dernier.

Ainsi, chaque contributeur possède les mêmes préférences. Les préférences locales s’écrivent dans des fichiers de config à la racine du projet. Ces fichiers s’appellent respectivement :

  • .htmlhintrc
  • .stylelintrc
  • .eslintrc

Il faudra également, pour la plupart des linters, installer quelques paquets via Node.js. Nous y reviendrons dans la partie suivante.

L’importance des linters est grande. Ils permettent à la fois d’assurer un style de code homogène et de détecter les erreurs syntaxiques.

Une grosse partie de la config de ces derniers repose en effet sur la partie stylistique. En effet, concernant la partie validité syntaxique du code, il n’y a pas à tergiverser. Soit le code est valide, soit il ne l’est pas !

Commençons par le plus facile de tous, htmlhint. Le fichier de conf se génère via le site du projet. Il n’y a pas énormément d’options. Voici le fichier tel qu’il est chez moi.

{
  "doctype-first": false,
  "tagname-lowercase": true,
  "attr-lowercase": true,
  "attr-value-double-quotes": true,
  "tag-pair": true,
  "spec-char-escape": true,
  "id-unique": true,
  "src-not-empty": true,
  "attr-no-duplication": true,
  "title-require": true
}

Mis à part doctype-first que je mets à false car il arrive souvent d’éditer des morceaux de templates qui seront insérés et n’ont donc pas de doctype, le reste se passe d’explications.

Ça se complique un peu avec stylelint. Comme il y a de très nombreuses règles, on part sur une configuration standard et on affine selon ses gouts au fur et à mesure.

{
  "extends": "stylelint-config-standard",
  "rules": {
      "indentation": 4,
      "selector-list-comma-newline-after": "always-multi-line",
      "number-leading-zero": "never",
      "declaration-empty-line-before": null,
      "order/properties-order": [
          "position",
          "top",
          "right",
          "bottom",
          "left",
          "z-index",
          "display",
          …
       ]
  }
}

Vous noterez peut-être la partie order/properties-order. Elle permet de forcer l’organisation du CSS via le pluging stylelint-order selon un ordre précis des propriétés. Certains préfèrent une organisation par ordre alphabétique, pour ma part, je préfère avoir mes propriétés organisées selon une logique fonctionnelle.

Ainsi, les propriétés CSS appartenant à un même groupe logique (ex. positionnement, bordures etc) se trouvent groupées. C’est plus ergonomique à l’écriture et à la maintenance et surtout, comme l’ordre et la répétition se compressent bien (Huffman inside), ça se compresse mieux !

J’avais regardé du côté des configurations prédéfinies de CSScomb pour organiser les propriétés. Libre à vous de faire votre sauce maison.

Abordons en dernier lieu la configuration d’eslint. Il n’y a pas de configuration par défaut officielle. Je pars donc sur la configuration de AirBnB qui repose sur leur style guide. De manière similaire à ce que je fais avec stylelint, je modifie ensuite la config pour l’adapter à mon style propre.

Je vous présente ma config sans autre forme de procès, ces préférences étant majoritairement des questions de goûts, inutile d’entrer dans les détails. Les commentaires sont toujours ouverts au besoin !

{
    "extends": "airbnb-base",
    "env": {
        "browser": true,
        "jquery": true
    },
    "globals": {
        "ga": true
    },
    "rules": {
        "indent": [2, 4],
        "func-names": ["error", "never"],
        "no-new": "off",
        "comma-dangle": ["error", "never"],
        "max-len": ["off", 120],
        "no-plusplus": "off",
        "no-underscore-dangle": "off",
        "no-param-reassign": ["error", { "props": false }],
        "brace-style": ["error", "stroustrup"],
        "import/no-extraneous-dependencies": ["error", {"devDependencies": true, "optionalDependencies": false, "peerDependencies": false}]
    }
}

Dans un second article, je vous présenterai comment tirer parti de NPM, le gestionnaire de paquets de JavaScript afin qu’il remplisse tout à la fois les rôles de gestionnaire de dépendances et de task manager. Nous n’aurons ainsi plus à installer et configurer 50 outils différents : one tool to rule them all!

Déjà 6 réponses, rejoignez la discussion !

    • Buzut

      dit :

      Yo!
      Je ne sais pas si ça fait partie de l’environnement de travail puisque d’un serveur à un autre, que ce soit OVH ou Leaseweb, mon ssh et mon Ansible ne voient pas la différence.

      Cela dit, je suis très content d’OVH. Le seul point noir, c’est le service client qui n’est pas d’une réactivité folle. J’ai des VPS qui tournent depuis des années sans broncher, des dédiés, et d’autres chez SoYouStart dont je suis très content. Le matos est fiable et ton serveur tourne tant qu’il n’a pas de problème technique ou qu’il est réparable.

      En plus, la nouvelle interface client est plutôt jolie et bien conçue et l’API est bien fournie, tu peux même renouveller tes certifs Let’s Encrypt par DNS sans trop te compliquer la vie avec acme.sh. Bref, que du bonheur, et pour une fois, c’est Français !

      Je gère des serveurs chez Online.net aussi. Ce n’est pas la même chose. Ils changent leurs gammes régulièrement, après cinq ans, les vieilles config doivent virer, donc on te force à migrer (pas super pratique). Ensuite chez Online, j’ai eu de très très nombreux problèmes techniques (majoritairement des problèmes de RAM et de disque). Là encore, bien souvent, on t’explique que le serveur n’est pas réparable et on t’en donne un autre :/

      Seul point positif, le support est plutôt réactif… Mais vraiment trop de problèmes. En revanche, je suis assez content de Scaleway (leur gamme VPS/Cloud).

      Tu utilises quoi toi ?

      Tchô !

  • Cascador

    dit :

    Salut,

    En fait les développeurs web préfèrent prendre de l’infogéré et je pensais que c’était ton cas mais si je comprends bien tu gères aussi l’administration, maintenance, sécurité des serveurs. OVH est un bon choix.

    Tcho !

    • Buzut

      dit :

      Yes, je gère tout moi-même. Avec Ansible, ce n’est pas extrêmement contraignant et malgré un peu de complexité et de travail supplémentaire, ça apporte une flexibilité dans la config et des performances plus élevées (IMHO).

  • Wololo

    dit :

    Tout a fait d’accord, OVH déchire. Le cloud souverain, le voilà. Et sans un sous public !

    Pour ma part, j’ai opté pour un VPS CoreOS provisionnée avec docker-machine. CoreOS est hyper simple à maintenir. J’utilise docker-compose pour orchestrer et des volumes pour persister. Tout est versionnable.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *