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

Connaissez-vous le livre " The innovator method " ? Non ? En ce cas, je vous le recommande. Surtout si vous vous demandez comment mener à bien l'innovation au sein de votre entreprise. Si je devais résumer (à mes yeux), ce livre nous montre comment faire face à l'incertitude, afin de lever les risques au plus et dans un minimum de temps et de coûts. De plus, ce livre nous amène à nous poser la question de comment découvrir les opportunités ou tout du moins, découvrir et formaliser un problème. Incertitude Incertitude. Ce mot, vous allez le trouver très souvent. Car c'est la clé. En effet, nous allons trouver le dilemme très récurrent dans une entreprise: - Se reposer sur le produit qu'on a (et donc qu'on maîtrise et connaît les risques), et le faire évoluer. - Se diversifier afin de couvrir un nouveau marché ou de résoudre un besoin, mais donc faire face à de nombreuses incertitudes (intérêt des clients / des fournisseurs ? le coût ? l...

Depuis la norme HTML 5.2, une nouvelle notion est apparue dans le moteur JavaScript, nous permettant à la fois d'améliorer le lalzy loading de nos applications et de faire un pas vers les progressives Web App: l'api IntersectionObserver . Le but de cet api: observer un ensemble d'élements et savoir s'ils sont visibles. Autrement dit, s'assurer que l'image est visible par l'oeil de l'utilisateur, aussi bien dans le viewport de notre navigateur que dans un élément de notre page. Prenons le cas suivant: C'est un cas très classique, où nous aimerions charger que les images qui ont besoin d'être vue. En effet, pour chaque image, un appel HTTP en "GET", sollicitant à la fois le serveur, mais surtout consommant de la bande passante (pas top dans un contexte mobile) et aussi sollicitant le navigateur. En effet, ce dernier (jusqu'à HTTP2) n'arrive à gérer que 5 appels HTTP sur son domaine. Du coup, si vous avez...

Cette article va être un peu fourre tout ça nous allons essayer de regrouper un certain nombre de terminologies que nous pouvons entendre dans le métier de développeur. Et du coup, cela peut nous aider en tant qu'aide mémoire :) Dans la façon de concevoir KISS Keep It Simple, Stupid! Cela veut tout simplement dire d'essayer de produire une architecture / un code le plus simple possible. Nous pouvons ainsi inclure pour le code le fameux principe du "No premature optimization" afin de rendre le code le plus simple et le plus compréhensible. Et ce n'est que si cela est nécessaire que nous allons optimiser le code (et en ce cas, bien documenter le pourquoi du comment) Nous pouvons rejoindre aussi l'outillage du projet. Par exemple, sur un projet utiliser "Bower" et "TypeScript" (qui sont en soient de bon outils) impliquent que les utilisateurs sachent configurer et utiliser pleinement ces deux outils (et dans le cas de Type...

Si vous utilisez SonarQ, il se peut qu'il affiche ce genre de choses: Ce qui est un peu stupide. Or il se peut qu'il affiche un grand nombre de faux positifs car: 1) Pas adapté au Web / JavaScript 2) Pas adapté aux frameworks comme Angular où nous avons potentiellement pleins de services à injecter dans le contrôleurs, et SonarQ va du coup nous sortir des erreurs car "trop de paramètres" Il existe néanmoins un moyen simple de remédier à cela. Dans le lien suivant, j'expliquer comment déclarer un sonar properties via jenkins:  http://julienroche.blogspot.fr/2017/07/jenins-sonar-et-application-web.html Il suffit de l'étendre afin d'injecter de la surcharge. Ces règles, vous pouvez les trouver sur le lien suivant:  http://dist.sonarsource.com/reports/coverage/rules_in_javascript.html Il suffit alors de spécifier les règles que nous ne souhaitons en utilisant le "sonar.issue.ignore.multicriteria": # Ignore...

Suite à l'article  Karma & Angular: charger des fichiers JSON "étendus" , je viens de publier un petit plugin pour aider au chargement de fichiers JSON, notamment ceux étendus:  karma-read-json5 Pour l'installer, il suffit de faire: npm install --save-dev --save-exact karma-read-json5 Pour le configurer, il faut bien penser à le déclarer à la fois dans la section "frameworks" mais aussi "plugins" de votre de configuration Karma: // Karma configuration // Generated on Sun Jul 16 2017 13:22:56 GMT+0200 (Paris, Madrid (heure d’été)) module . exports = function ( config ) { config . set ({ // base path that will be used to resolve all patterns (eg. files, exclude) basePath : ' ' , // frameworks to use // available frameworks: https://npmjs.org/browse/keyword/karma-adapter frameworks : [ ' jasmine ' , ' readJSON ' ], // list of files...

J'utilise depuis longtemps le plugin " karma-read-json " qui est utile pour mes tests. En effet, cela permet de vérifier que mes services par exemple produise le bon modèle en sortie en se basant sur un appel REST. Du coup, je me fais un mock JSON de mon appel REST (issue très souvent d'un vrai appel pour être au plus prêt de la réalité) et je construis un fichier JSON qui contient le JSON espéré. Cela me permet de vérifier la non-régression de mon code mais aussi de fournir des exemples concrets de JSON que l'application va devoir manipuler. Parfois, dans les modèles que je définie dans mes services, je fais des modèles un peu plus complexe, qui peuvent contenir des valeurs comme "Infinity". Or l'api JSON présent dans nos navigateurs et dans les moteurs EcmaScript ne gère pas ce genre de valeurs, car se base sur la norme définie sur le lien suivant: http://json.org/ Cela est d'autant plus dommage que nous ne pouvons pas mettre p...

Bonjour Voici un petit exemple de configuration d'un job jenkins (et aussi un peu de son projet Web) afin de lier les résultats de tests et de couverture de code vers Sonar, en prenant bien en comptant certains soucis. 1 - Ne mettez pas d'espaces Aussi bien dans le nom du projet Jenkins que dans le chemin d'accès aux fichiers Junit / LCOV, vous ne devez pas mettre d'espaces. Ceci est indispensable, autrement, le plugin Sonar (et en règle générale, les plugins Jenkins) ne trouveront pas les fichiers (car ils ont tendances à ne pas échapper les espaces). Du coup, dans votre fichier karam.conf.js (par exemple), il est bien de préciser un emplacement "en dur" de vos fichiers de résultats: { // test results reporter to use   // possible values: 'dots', 'progress'   // available reporters: https://npmjs.org/browse/keyword/karma-reporter 'reporters' : [ 'junit' , 'coverage' , 'progress'...