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

Sass est un pré-processeur CSS très puissant, notamment grâce à l'usage de ces mixins. Ces derniers sont à considérés comme des fonctions qui, en fonction de paramètres, va générer un CSS qui va pouvoir s'injecter dans notre code. J'aimerai vous faire part d'une petite astuce qui permet de rendre flexible l'usage de ces derniers. En fait, je suis tombé un peu comme on peut l'avoir avec des fonctions JavaScripts: je voulais fournir un nombre de paramètres "importants" (pour moi, dès que cela dépasse 3 paramètres, cela commence à devenir important). Du coup, en JavaScript, vu que nous n'avons pas de polymorphisme de méthodes, pour éviter d'avoir des méthodes qui ont trop paramètres, on essaie de passer par un objet intermédiaire. Prenons le cas où nous voulons récupérer une liste d'utilisateurs: /**   * @ method   * @param {UserQuery} [query=null]   * @param {string} [direction='asc']   * @param {number} [pageS...

Ici, c'est pour parler d'une problématique que ne couvre pas les applications évoquant la programmation réactive: à savoir la partie où les données qui doivent transiter sur le protocole HTTP. En effet, je vois beaucoup d'articles qui disent que si nous utilisons Spring Flux côté backend et Angular côté frontend (par exemple), nous avons alors une application qui est totalement réactive. Sur le papier, c'est vrai. Dans la réalité, c'est une autre histoire. Et pour cela, nous allons nous faire une mise en situation. Création de l'application Créons une application Spring Flux. Pour ne pas s'embêter, nous allons utiliser cet excellent article  https://www.baeldung.com/spring-webflux et récupérer le code source sur  https://github.com/eugenp/tutorials . Faisons un "mvn clean install" et dirigeons nous vers le répertoire "spring-5-reactive-security". Dedans nous allons trouver un contrôlleur REST basé sur Spring Flux, qui...

Le 9 novembre 2018, au dock Pullman de Paris, a eu lieu la dotJs . Cet événement rassemble chaque année la communauté de développeur JavaScript à travers le monde en proposant seulement un seul track mais avec comme speakers beaucoup d’acteurs majeurs ou représentatifs. Le tout entrecoupé de ligthning talks de 5 minutes. Cela fait depuis 2014 que je vais aux différentes éditions, et si je devais comparer celle-ci aux autres, je dirai qu’elle m’a déçue. Surtout par rapport à l’édition de 2017 qui était pour moi fantastique. Notamment des sujets comme l’usage du machine learning pour l’accessibilité, sur comment s’assurer que son site est accessible, sur pourquoi certaines choses disparaissent dans nos navigateurs pour éviter des failles, ou encore une personne qui a expliqué comment en NodeJs intercepté et comprendre les données de positions des avions et de les afficher. Si je devais résumer les points négatifs: je trouve que les speakers et les sujets n’étaient ...

SonarQube et le Web: un passif lourd... Il est vrai qu'il est frustant de faire des projets en JavaScript / NodeJs, ou en Web, et que nous ayons à passer dans SonarQube. Alors que de principe, c'est important d'utiliser un outil de ce genre ! En effet, SonarQube est un outil qui permet de faire un suivi en continue de la qualité du code. Il permet ainsi de remonter (et de versionner) les "code smells". Ces derniers sont des erreurs d'écritures de code (plus ou moins critiques) et qu'il vaut mieux de corriger. Nous pouvons voir également un code coverage associé, ainsi que le taux de duplication de code, des statistiques sur les fichiers, etc ... Le hic survient quand on voit pour quelle technologie était faite à la base SonarQube: Java. Et le soucis est bien là. En effet, il faut savoir que pour générer un code smell, il faut créer des plugins Sonar avec des règles non dynamiques (dans le sens où nous ne pouvons pas à notre guise ajouter...