Julien Roche - Développeur avancé JavaScript, Web et Java

Il y a quelques années de cela, j'avais rédigé pour le site developpez.com un article sur les fondamentaux du responsive design . Le principe même du responsive design est de fournir, en se basant sur des outils, un résultat qui est inhérent aux matériaux / supports. Cette phrase peut sembler abscons mais veut dire tout simplement que nous ne nous limitons pas au support afin de réaliser nos oeuvres. Dans le monde Web, cela se traduit par la réalisation qui ne dépend ni d'un type de navigateur (encore moins d'une version), ni du support (desktop / mobile), ni même de la résolution d'écran ou de son ratio. Il existe de nombreuses solutions côtés navigateurs pour cela: que ce soit les Media Queries CSS3 afin d’adapter l'affichage en fonction de la résolution, des frameworks comme device.js qui nous indique sur quel support nous sommes (quel orientation également, etc ...). Ce qui va nous permettre encore une fois de soit adapter l'affichage, soit ...

WebStorm embarque par défaut un serveur Web qui expose nos applications sur http://localhost:63342/ . Néanmoins, quand nous souhaitons accéder à l'application depuis son mobile, cela ne fonctionne pour des raisons de sécurité. Vous pouvez pallier à ça en demandant à WebStorm de ne pas exposer sur le port 63342, mais plutôt sur le port 80 ou 8080. En faisant cela, vous pourrez faire le "debug" à distance. Cela se site dans "settings / build / debugger". Changer donc: Le port (à 8080) Cocher la case "Can accept external connections"

Nous oublions souvent une chose: des personnes qui ont des déficiences visuels, cognitives et de mobilités veulent naviguer sur nos sites. Du coup, ils auront sur leur poste des outils qui vont "lire" notre site Web afin de mieux les aider. En France, il existe une norme se nommant "RGAA" qui référencent les points d'attentions et également les démarches à réaliser sur la conception de notre site (respecter des gammes de couleurs, mettres des titres sur les liens ...):  http://references.modernisation.gouv.fr/rgaa-3-0 Après, il n'est pas toujours évidemment de savoir si ce que nous avons fait respect parfaitement ces conventions. Addy Osmani (encore lui) nous fournit un outils sur NodeJs qui va analyser notre site Web et nous donner des indications de modifications: a11y Même si cet outils ne couvre pas tout, il a vous permettre de dégrossir notre travail. Pour l'installer, rien de plus simple: > npm install -g a11y En...

Cet article a pour vocation de faire découvrir une commande méconnue de NPM qui est shrinkwrap. Nous allons avoir que dans un context projet et surtout avec une équipe, cela a un sens important de l'intégrer dans son cycle de vie. Petit rappel de ce qu'est la convention "semver" Pour rappel, la numérotation d'un module NodeJs se repose sur la convention  semver . Le principe est simple: nous avons une version basé sur trois chiffres, séparés par des points. Le premier chiffre est le "major version". Cela veut dire que lorsque ce numéro change, nous avons un changement majeur dans le module, apportant potentiellement des "breaking changes". Donc en générale, quand nous mettons à jour un module dont le premier chiffre change, nous pouvons nous attendre à avoir à réadapter notre code. Le second est le "minor version". En somme, c'est tout simplement une version stable. Mettre à jour un module dont seul le deuxième numé...